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In this Issue 

In the early days of factory automation, it was 3 lot easier to automate individual 
processes or workcells than an entire factory. The re suit was islands of auto- 
mation, each representing the best available solution to an individual need but 
incapable of communicating easily with other islands or with higher-level sys- 
tems because of differences in computers, interfaces, languages, operating 
systems, and applications. Yet the goaf has always been the integrated factory, 
or CIM — computer-integrated manufacturing. The development of advanced 
networks and communication protocols such as MAP (see the August 1990 
issue) has brought the integrated factory closer to realization, but it can still be 
a formidable task for a system integrator to provide for transparent communica- 
tions between diverse applications designed for different computing platforms. HP Sockets, our cover 
subject, is a product that helps system integrators overcome incompatibilities and provide file and mes- 
sage transfer between applications running on different network nodes. HP Sockets runs on and provides 
communication between HP computers using the HP-UX and MPE XL operating systems. It can also com- 
municate with non-HP svstems through a gateway, an HP-UX node that uses a client/server model to ex- 
tend HP Sockets capabilities to machines not using the MPE XL or HP-UX operating systems, Using HP 
Sockets, a system integrator creates application adapters, which allow applications to JJ plug into" the HP 
Sockets system Data coming from an application is translated to an internal common data representation 
format. Outgoing data is converted from this format to the format expected by the destination application. 
The system provides a data manipulator to resolve differences in data structures and languages and a 
data transporter to move the data from origin to destination, guided by user-created configuration files 
describing the environment The full story of HP Sockets design, operation, and performance can be found 
in the article on page 6. 

With the use of structured analysis and structured design becoming commonplace in software engineering, 
where do we find the leading edge today in industrial software development methods? One range of methods 
thats definitely leading-edge is rigorous software engineering, also called formal methods — rigorous, abstract 
mathematics applied to software specification in an attempt to head off defects right at the start. HP Laborato- 
ries in Bristol, England has been working on formal methods for several years, and one of these methods— the 
HP Specification Language, or HP-SL — has reached a stage of development where it's ready to be used in real- 
world software projects. The idea is to develop an abstract but precise description of the behavior of the soft- 
ware system. This description can be reviewed to ensure that the system works properly and that defects are 
not introduced because of deficiencies in specifying the required behavior. Although software behavior can be 
specified using a natural language, rt J s difficult to do so unambiguously. Formal specification languages like 
HP-SL use special syntax and special symbols based on discrete mathematics to avoid the ambiguities of natu- 
ral language. The motivation for this approach and an overview of the symbols and syntax of HP-SL can be 
found in the article on page 24 Examples illustrating the use of HP-SL are presented in the articles on pages 32 
and 40, which show how an electronic mail system and a real-time alarm monitor are specified. In the articles 
on pages 46 and 51, software engineers from two HP product divisions relate their experiences with HP-SL in 
actual product development projects. 



[>ii ember \'J\t\ Hewlett-Packard Journal 

©Copr. 1949-1998 Hewlett-Packard Co. 



Network monitoring can mean many things, depending on the type of network and the reasons for monitoring 
Some typical objectives of network monitoring are to measure traffic and plan for future needs, to determine 
the quality of service, and to identify and locate faults. More and more, network monitoring is a distributed pro- 
cess, wrth measuring devices permanently installed throughout the network reporting to a central computer. 
The HP E3500A telecommunications network monitoring system described in the article on page 59 is a distrib- 
uted system for monitoring telephone networks, mainly outside North America and Japan, that use the 2-mega- 
bit-persecond primary rate interface and the CCITT (International Telephone and Telegraph Consultative Com- 
mittee) R2 or Number 7 signaling systems. Peripheral units connected to the network collect and preprocess 
data on various network parameters and transmit their measurements to a central computer, which elaborates 
the data anrj provides the user interface. The parameters measured, some of which are specified by the CCITT, 
are related to traffic intensity and type, the quality of service, and network efficiency and use. 



December is our annual index issue. You'll find the 1991 index on page 69. 



R.P. Dolan 
Editor 



Cover 

An artist's rendition of a typical HP Sockets domain (a less artistic rendition is given in Fig, 1 on page 6). The 

cable-like strand going through the center of the spiral represents a LAN and the panels connected to the 
strand represent diverse applications that are communicating with each other via HP Software Integration 

Sockets. 



What's Ahead 

The February issue will have several articles on the design of the HP 54B00 digitizing oscilloscopes, These are 
100-MHz oscilloscopes that have the rapid display update rate characteristic of analog oscilloscopes along 
with the data storage advantages of digital oscilloscopes, The HP LanProbe monitors and HP ProheView soft- 
ware for distributed monitoring of local area networks will be described in another article, A tutorial paper on 
neural networks will present the basic concepts of these computing architectures. 
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HP Software Integration Sockets: A 
Tool for Linking Islands of Automation 

The task of integrating diverse applications over a network of HP and 
non-HP machines is made easier with this software tool. 

by Mitchell J. Amino, Cynthia Givens, Mark Ikemoto, Alan C, Miranda, Scott A. Gulland, 
Kathleen A. Fulton, and Irene $♦ Smith 



HP Software Integration Sockets [HP Sockets) is a soft- 
ware tool that enables efficient and reliable integration of 
new and existing software applications in a network of 
different computer systems and diverse applications. HP 
Sockets is designed to help system integrators overcome 
problems that are common in software integration and 
difficult to solve. HP Sockets provides a comprehensive 
set of communication features that are both broad and 
deep. It is intended to fulfill the needs of interappl teat ion 
communications for file and message transfer. Messaging 
functionality is particularly extensive for bodt random arid 
sequential synchronous and asynchronous, destructive 
and nondestructive data transfers. Communicating pro- 
cesses can be written without regard to language, com- 
puter type, or network topology. Tlie same methods of 
communication can be used for either local or remote 
communication in a homogeneous (same machines and 
operating systems) or heterogeneous (different machines 
and operating systems) environment, Fig. 1 shows some 
typical applications that could he integrated with IIP 
Sockets, 

MP Sockets runs on HP 9000 Series 300, 400 f 700, and 
800 Computers running the HP-UX* operating system, and 
HP 3000 Series 900 computers running the MPE XL oper- 
ating system. Sockets can also communicate with non-IIP 
systems (see "HP Sockets Gateway on page 20). 

After a brief overview, this article will describe the opera- 
tion and implementation of Ihe major components of HP 
Sockets. 

Overview 

Using HP Sockets, a system integrator can shorten the 
system integration time by up to 75%. HP Sockets helps 
shield system integrators from all the vagaries of network 
interfaces and differences in hardware and system soft- 
ware. HP Sockets also helps resolve data mcompatihililies 
between communicating applications. For end users, HP 
Sockets offers flexibility in the management of an inte- 
grated system. System configuration can be easily 
changed because HP Sockets supports incremental inte- 
gration so that new hardware or software can be added 
without modification of the existing links. 

The major problems involved in integrating new and ex- 
isting software applications result from the differences in 
hardware platforms and their associated operating sys- 
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Fig. i. Kxampi^s pfttee tyju' $f applications that mi^iii lie integrated 
in the HP Ben, ke&s doinain. 

icnis. and differences in the applications themselves. Spe- 
cifically, these integration problems include: 

• Differences in hardware platforms and operating sys- 
tems. Because computers are built on diverse hardware 
architectures and operating systems, data from applica- 
tions running on one system is often not usable on anoth- 
er system. 

• Diverse network services. Programmers must change 
application code to create interfaces to different sets i >i" 
network services. 

• Incompatible data types. Different applications use differ- 
enl data types according to iheir specific needs. Program- 
mers must write code to con veil the data from a sending 
application into lypes that a receiving application can 
use. 

• Differences in data structures. Incompatible data struc- 
tures exist because applications group data elements in 
various ways. For example, an element with a common 
definition may be stored in tun different ways: applica- 
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Administration Components. The administration components 
include: 

• IIP Sockets Manager. The 1 IIP Sockets manager tefs the 
user validaie configurations, sum up and shut down the 

HP Sockets system, use the command processor, and 
perform other HP Sockets management ('unctions. 
Command ptfoesssot. The command processor allows 
interactive testing of the messages antl links in any pro- 
cess within the UP Sockets domain. An HP Sockets do 
main is an en\ nonment consisting of all the not Irs thai 
are integrated via HP Sockets 

• HP Sockets Management I )aemon (SMS). Thfe process 
assists the III* Sockets manager in performing niana^e- 
meni tasks on local and remote nodes thai air pari of the 
HP Sockets domain. 

• Configuration Rk& The configuration files are user 
created files containing information about the IIP Sockets 
domain. A; the startup of this domain, information in 
these configuration llles is used to build the memory resi 
dent rontigmation tables Tot the run-time part of HP 

ockets i see ^Configuration Flies" on page l->). 

System Integrators 

As a software tool for system integration, IIP Sot kits is 
nol a stand-alone solution. HP Sockets is one of many 
components that make up an integrated system. The par- 
ticipating applications play a major part. HP Sockets pro- 
vides a foundation for the I inky between these applica- 
tions, but these links have to be bnill by system 
integrators. The tasks the sysiem integrator must perform 
to integrate applications with IIP Sockets Include: 

• System analysis. The system Integrator must determine 
the system functional requirements, analyze data flows 
between applications, determine data formats of I lie data 
flows, and define the characteristics of each link. 



i >vsteni design. By determining the hiiieliounl require 
menisaiid b\ analyzing the dala Hows and data formal 
the system integrator will be able In design the bridges 
betwtrn Hie applications and IJI'SurkHs in Other 

words, design the application adapters. 
• Configuration. Aft ei building the application adapters, the 
next task for the system integrator is to configure the 
integrated system. < nnilgurai ion means describing to IIP 
Sockets the network topology, the participating pro 
cesses, and the data formats and data manipulations rhai 
HP Sockets will need to perforin lor each link w hen ir 
transfers data helween communicating applications 

Run -11 me Architecture 

The IIP Sockets run-lime architecture is designed lo pro- 
vide the best performance possible while using minimal 
syslejn iesr naves. IIP Sockets builds bts run lime modules 
u 'I activates them across the network without requiring 
user intervention. 

Two main components make up the IIP Sockets nuw 

architecture: the thna transporter and the data manipula- 
tion module. Kacii component is implemented as one m 

more programs and consists of several modules (see Fig. 
4 |, The architecture show r n in Fig. 4 exists on every nude 
integrated via HP Sockets, 

Data Manipulation Module. On the sending node this mod 
ule performs two operations: it manipulates outgoing data 
into a formal acceptable to the receiving application and 
it encodes the data iniu a common dala representation. 
The encoding operation is called mm*$h$Ling <\\u\ the 
common dala representation is a language anil machine 
independent data format, The incoming network manager 
on the receiving machine uuniaisluls the data (i.e. ton- 
verts it to local machine and language representation). 



Unmanipulaled Messag 
Manipul 



ssage A 

ated Message 



Request 



Request 
Manager 



Status 
and 
Data 



File 
Information 



Dala 

Manipulation 

Module 



Fife 

Handling 
Module 



File _ 
Nolitication 

— ► 



Outgoing 
Network 
Manager 



Incoming 
Message 



Incoming 
Network 
Manager 






Requests and Data from Network 



Requests 



Application 
Adapter 



Application 



' Data Transporter 



Error logger 



HP Sockets 

Management 

Daemon 



Run- Time 

Configuration 

Tables 




Fig. 4, III 1 Sockets run-tnru an h: 

re. 



8 peri mi her 199 J NtulHi Packard JounmJ 



)Copr. 1949-1998 Hewlett-Packard Co. 



For more about marshaling, common data representation, 
and data manipulation* see "Data Manipulation" on page 
20. 

Request Manager. This module routes application adapter 
requests through the internal HP Sockets modules to the 
requests eventual destination. The data messages it re- 
ceives from the incoming network manager are stored 
until an application adapter issues a read request The 
st manager handles only requests and leaves the 
data manipulation and tile transfer tasks to other mod- 
ules, Requests include message transfers, file transfers, 
and local or remote program control 

Outgoing Network Manager. This module sends messages 
uver the network. If communicates with the incoming 
network managers on the other nodes. It creates and 
holds communication open to other nodes as required. 
Resource use is minimized because this module is shared 
by all the processes on a node, and it can clone itself as 
resources are needed. 

Incoming Network Manager, This module receives messages 
from the outgoing network managers on other nodes. 
When it receives data it converts (un marshals) the data 
from the common data representation that is used across 
the network into its hosi node's local representation. The 
data is passed to the local request manager for delivery. 
To optimize resource use, the incoming network manager 
also clones itself to meet its needs. 

File Handling Module. This module transfers files between 
nodes. A process can request a file to be transferred and 
a notification to be sent to the request manager on the 
receiving node when the file arrives. 

The cnor logger and the run-time configuration (abies 
shown in Fig, 4 are used by both the data transporter 
modules and the data manipulation module. The error 
logger logs any errors <>r notable events (e.g., startups, 
shutdowns, etc.) detected during run-time operation. Ac- 
i-ess routines are provided so that the user can log user- 
defined messages using the error logger. 

The run-rime configuration tables contain data I bat IIP 
Sockets €*xtracts from the configurattoil files Tor nm time 
operation, such as node names and data manipulations. 

Kim-Time Operation 

The run-tinu" operation of HP Sockets on a sending node 
typically begins with Hie request manager receiving re- 
quests from an application adapter to perform a Specific 
task such as to send a message or file, or to retrieve a 
message Fig, I shows the data Hows during these opera- 
tions. If the request manager receives a request to send a 
message thai is destined for a remote node and the mes- 
sage does not have to be manipulated, the message is 
sent directly to the outgoing network manager. When a 
message has to be manipulated, the request manager 
sends the message to the data manipulation module. After 
manipulating The message, the data manipulation module 
sends the message to the outgoing network manager. If 
[lie request manager receives a request fo send 8 U\*\ 11 
notifies flie Hie handling module, which sends the file and 
then sends a file notification message to the outgoing 
network manager. The outgoing network manager for- 



wards the file message to the incoming network manager 
on the remote node. 

I rn the remote node the incoming network manager sends 
the message to its request manager If the file message 
has file notification turned on. the request manager sends 
a signal notifying the receiving application that a file has 
been sent to it. If file notification is not turned on, the 
application is not notified about the file sent to it. Status 
messages indicating s r failure of a request are 

returned to the sending application adapter when a re- 
quest is made wiih wait. 

i ip and shutdown are synchronized between the run- 
time modules. After the run -time modules are started, 
they perform initialization. All modules complete initializa- 
tion and wait before they are allowed to process data so 
that if one module fails to initialize, startup can be 
aborted. Also, modules have some interdependencies that 
need to be resolved before data processing begins. For 
example, since modules rely on each Others 1 system no .-s- 
sage facilities such as message queues, these facilities 
must be created by each module before data processing 
can begin. The IIP Sockets management daemon is the 
process that notifies modules lo start processing data. At 
shutdown, the IIP Sockets management daemon notifies 
all modules to shut down To pre\ em loss of messages in 
transit between modules, modules perform a graceful 
shutdown by sending last messages to the appropriate 
modules before terminating. The HP Sockets startup and 
shutdown functions are described in more detail later in 
this article. 

Adapters and Access Routines 

To link existing applications without requiring them to 
change, a bridge is needed between an application and 
HP Sockets. That bridge is called an application adapter 
(see Fig. 5). An adapter is usually a program, Inn it could 
he a procedure If the application is capable of calling 
ii a i \ -- wri tt en routines. 

Application adapters are created with the access routines 
supplied by IIP Sockets- This program malic interface con- 
sists of HP Sockets routines i allable from t\ R jRTRAN, 
COBOL, or Pascal programs to send messages, copy 1 1 
Control processes, and so on. Any program or procedure 
thai uses an HP Sockets access routine is, in effect, an 
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application adapter. The user determines how an applica- 
tion adapter is Implemented 

There are I wo main functions in an adapter data access 
and interfacing. 

• Data Access, The data access function retrieves data 
from the application or delivers data lo the application 
Data access can be as simple as reading an application 
data file or accessing the applications data base. 

• Enterfaeing. This means UBittg IIP Sockets access routines 
in iransmit data between applications, or asking UP 

S< n kets lo si a 1 1 <>r stop another process. 

Once the scope of die adapter is determined, l he features 
of EBP Sockets need to be factored into the design. The 
adapter will use these features through the HP Sockets 
access routines given in Table L These routines are I he 
door through which the UP Sockets world is entered 
They are easy to learn, consisting or only L2 procedures 
which completely shield the interface developer from die 
network services levels. All functionality is expressed in 
functional terras such as read message, send message, 
send files, and so on. Sophisticated interfaces can be 
written with minimal programming. 

IIP Sockets provides a way to exercise these access rou- 
tines interactively. This is done using the IIP Sockets 
command processor. The command processor is a pro- 
gram that has a set of line mode commands that allow 
the user to simulate an adapter using access routines. 
i >n<c IIP Sockets has completed startup, with the com- 
mand processor the user can read or send messages or 
files, and start or slop a user process. Data can be sent 
or displayed in either ASCII or binary. 

The command processor can be used to lesl newly im- 
plemented adapters, Pig. 6 shows an example configura- 
tion consisting of two adapters, adapter 1 and adapter 2, 
Adapter 1 sends messages to adapter 2. If adapter 2 does 
not receive the message sent from adapter 1 the error 
can be found as follows: 

• Test 1 

Shul down adapter I and set up the command processor 
lo simulate adapter 1. 
o Using the command processor, send a message to adapter 
2 using the same formal as would be sent by adapter 1. If 
adapter 2 receives the message correctly, then the defect 
is in adapter I If adapter 2 does not receive the message 
or receives an incorrect message the defect may be in the 
configuration or adapter 1. 
Proceed to test 2. 



Command 
Processor 



Test 2 




Command 
Processor 



* Test 2 

Shut down adapter 2 and set up the command processor 
to simulate adapter 2. 

Start up adapter I and receive (he message with the com- 
mand processor. If the command processor can receive 
the message correctly from adapter 1, the the defect is in 
adapter 2. 

Table I 

MP Sockets Access Routines 

Access Routine Description 

These routines control adapters, 

Splnit Initiate communication between HP 

Sockets and a calling process. 

SpEnd End communication and clean up 

resources allocated for the calling 
process by HP Sockets. 

SpStartProcess Start an HP Sockets configured 

user process. 

Sp Stop Process Stop an HP Sockets configured user 

process. 

SpErrLog Log a user error message in the \]P 

Sockets error logfile. (Send appliea- 
li uii -specific messages to the HI' 
Sockets error logger) 

Retrieve ASCII messages corre- 
sponding to the HP Sockets error 
codes returned by routines. 

control data transfer between appli- 

Send a message to a local or remote 
process. 

Copy a file to a destination file on a 
local or remote node. 

Control the HP Sockets access rou- 
tine oplions (such as timeout or 
message notification ) that are avail- 
able to the calling program. 

SpReadQ Read messages from the incoming 

message queue for the process. 

Sp Flush Flush pending requests and clear 

the timeout list for the process. Use 
this only when doing a longjrnp out of 
an interrupt routine. 



SpError 



These routines 
cations. 

SpSendMsg 



SpSendFile 



SpControl 



SpDelGuaranteedMsg 



Remove a guaranteed message 
from the guaranteed message spool 
file. 



- Test Connections 
Fig. 6. Testing application adapters. 



Data Transport 

Data communi cation between an application and HP 
Sockets starts with the application adapter making a call 
to the the access routine Spirit to initiate communications 
with HP Sockets (see Pig- 7). This call sets up message 
transfer facilities [message queues for HP-UX and mes- 
sage files for MPE XL) for data and status messages be- 
tween the application adapter and (he request manager 
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and generates an initialize request to the request manager. 
The initialize request contains information such as the 
calling adapter's logical name* iis process identification, 
and Us uev. | message queue identifier The re- 

quest manage mmunication links for the 

calling \ ■ s already stored in the run- 

time configuration table) and returns a status mess; 
t el h I call was sun ess ful < h 1 1 

unieaiion link is enabled with -ful 

Splnit call, it can make calls to any of the otter HP S 
ets access routines, 

The HI* Sockets access routines handle all data transport 
between an application and ihe HP Sockets system. The 
mam routines used For (lata transport are SpSendRle, 
SpSendMsg, and SpReadQ (see Tattle I}. All access routines 

communicate between iheir railing program and flu re- 
quest manager, whose main function is id receive re- 
quests and muii them between other internal modules, 
and between local and remote application adapters. As an 
example-, the application adapter on the sending node 
initiates a (Sail to SpSendMsg. sending: 

• A data buffer 

• A destination process logical name (on a remote node) 

• An optional link logical name which indicates that data 
manipulation must be done before data goes to the outgo- 
ing network manager 

• A no-flags-set parameter, which indicates send with wait. 

After some preliminary error checking, (he SpSendMsg pn- 
rameters arc [>ui iuio the \iv Sockets standard message 
structure and the message is sent to the requesi manager 
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Fig. 7. Structure i h.>i r showing i|im communication I \) • ''■'■■ be* 
n the requesi Rianagerand some ol the KPSot ket i i rou 



Since ihe routine was called with wait, the SpSendMsg call 
will not return to tfae Galling routine until it either re- 
ceives a status value back from tin manager 01 

- out. 

When the request manager receives the message from 
SpSendMsg, it validates ihe :icaJ 

narm efiguran 

and then rh« on- 

rigu' mote node. If this is the rase, the 

requesi manag the outgoing nn- 

', manager to sei up comrairaiealton node if 

it is noi already done. Next, the logical link name is ex- 
amined. If it is non-NULL a message is sent to the data 
manipulation module, where the dat -saged accord 

ing to the manipulations associated with that link name. 
After the uianipui.i done, u tge is encoded 

intcft ihe common data representation formal and sen! to 
the outgoing network manager Hu transfer to the remote 
node. If a link name had noi been specified (i.e., a NULL 
link native j. the message is sent directly from the requesi 
manager to the outgoing network manager, bypassing the 
data manipulation module completely, 

When the requesi manager on Ihe remote node receives a 
message (via the incoming network manager), it stores 
the message in its memory area. When the message is 
successfully stored, a return message containing die sta- 
tus of the transfer is sent back to the originating (loral I 
node via ihe remote node's outgoing network manager 
The local incoming network manager receives i to- return 
message, urunarshals it. and passes it n> the local request 
manager. The local requesi manager sends it back to the 
adapter that originated the access routine call, completing 

the wiih-waif SpSendMsg caB 

once a data message arrives for a process on the destina 
(ion node, ihe message is not senl to the destination 
adapter until the data is explicitly requested by a rail in 
SpReadQ from the destination adapter Until that call is 
made, dala messages for all local processes are stored in 
an area Of shared memon called the shared memory ines 

sage area (an exception is guaranteed messages, which 
are described later). 

The destination adapter has two ways of finding onl if it 
has S data message waiting; polling and interrupt notifica- 
tion. Polling involves continually making calls to SpReadQ 

■ if there is a message. There ran be a user-specified 
timeout for each of these calls. If a Large enough rimeoul 
is specified, the adapter will block until a message arrives 
Tor it. Interrupt notification involves turning on the data 
or file notification feature 6t IIP Sockets, When turned 
on, a notification (via a signal from IIFM'X) is sent to the 
destination adapter when a data message or file arrives 
Tor thai adapt it. This feature '^ set up by Ihe destination 

adapter through ihe use of the SpControl access routine. 
The adapter originating a SpSendFile or SpSendMsg call does 
not know whether the destination adapter has set up noti- 
fication 

The SpReadQ message is seal to ihe requesi manager, 
which scans its memorj area to find data message 
elated wiih the calling adapter. If the correct data mes- 
sage is found (particular messages can be requested using 
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the Sp Re ad CI tag parameters, or by specifying the logical 
name of the sending process whose message the receiving 
process wishes to read), it is removed from the shared 
memory message area and sent to the calling adapter. 

If an incoming message needs to be put into the shared 
memory area, and either the whole memory area has 
been filled or the user-configurable percent allocation for 
a single process has been reached, the message is written 
to a special overflow spool file. This file will hold all sub- 
sequent messages for that process until space is freed in 
the shared memory message area by calls to SpReadCL 
Anytime a successful SpRearJQ is done for a process that 
has overflow messages, the overflow T messages are read 
from the file into the shared memory area This is done 
until the memory area limit is reached again or until the 
overflow spool file is emptied. 

When the SpSendMsg access routine is called, a flag called 
the guaranteed flag can be set. Setting this Hag tells the 
nation request manager to write the data message to 
a disk Hie rather than put: it into the shared memory mes- 
sage area The SpReadQ call done by the destination pro- 
cess must likewise set this flag so that the disk file is 
searched for the data message rather than the memory 
area. It is slower to send and receive a guaranteed mes- 
sage than a nonguaranteed message because of the over- 
head of disk access. However, the benefit of a guaranteed 
message is that the data will not be lost if a power fail- 
ure occurs. The shared memory message area cannot be 
recovered after a power failure. 

Guaranteed messages can be deleted using an option in 
SpReadQ, but to be absolutely sure that the data has been 
received (he data should first be read with a flag indicat- 
ing that the message is not to be removed from the disk 
Hie (using the no-consume flag), then as a separate step a 
call should be made to the SpDelGuaranteedMsg access rou- 
tine to delete the message. A drawback of guaranteed 
tu< >s;iges is that they can only be mad in the order they 
were received by the request manager; they cannot be 
retrieved by their tag values, or by specifying Hie logical 
name of the sending process. 

Network Interface 

The outgoing network manager and the incoming network 
manager are the modules within HP Sockets responsible 
for transferring messages across the network. Optimum 
performance is the reason network input and output tasks 
are dhided between these two modules. 

The incoming and outgoing network managers currently 
use NetlFC 1 mtrinsics to interface with the network pro- 
tocols. (BSD sockets can be used by HP-UX nodes run- 
ning HP Sockets provided that there are no MPE XL 
nodes in the HP Sockets domain. MPE XL does not cur- 
rently support BSD sockets.) With NetlPC. communication 
between the incoming and outgoing network managers 
involves establishing a virtual circuit connection, which is 
referred to as a virtual circuit socket descriptor. Multiple 
socket descriptors are needed for communication be- 
tween multiple nodes. Socket descriptors are allocated 
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Fig. 8. Outgoing and incoming network manager processes and tl kit 
connections. 

from the same space as file descriptors. A process is lim- 
ited to a certain number of file and socket descriptors 
that it can have open at any given time. The design of 
the outgoing network manager and incoming network 
manager allows HP Sockets to communicate with several 
nodes at a time by having the two network managers 1 
parent modules (Qnmp t Inmp) fork child processes (Onmc T 
Inmc) as needed to establish and hold connections (see 
Fig,S). 

When an Onmc or an Inmc reaches its maximum number of 
connections, another Onmc or Inmc process is created. The 
parents manage the children and do not hold any connec- 
tions themselves. 

When the request manager needs to send a message to a 
particular node for the first time, it notifies the Onmp, 
which in turn assigns an Onmc process the responsibility 
for communicating with that node. Alter the Onmc process 
successfully establishes a connection with the remote 
Inmc, ihey exchange a message to ensure that the IIP 
Sockets configuration is a compatible version on both 
nodes. If the versions are not compatible, communication 
is terminated. Otherwise, the Onmc process can send mes- 
sages it receives from local processes to the Inmc on the 
destination node. After receiving a message, the Inmc un- 
marshals the message and sends it to the local request 
manager, which is responsible for routing the message to 
the end application. 

If an Onmc fails to establish or maintain communication 
with a node for any reason, such as a node or network 
failure, it spools to disk all messages that the sending 
application specifies as critical and that are destined for 
the node associated with the failure. 

■±d nn page "4| 
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Configuration Files 



Configuring an HP Sockets system requires trie user w create 
files These six fifes, which can be created wrtf. aoy text editor, describe m \W 
Sockets in complete detail the HP Sockets operating environment with information 
such as the participating nodes, the communicating processes, and the Gala to be 
transported Fig 1 shows the s*x rant _ and the specific items r 

matipo that associate each file with r These tile^ =d tn 

any order using the information gathered in the system analysis phase. Only the 
first two files, NETWDEF and PROCDEF are required to describe an HP Sockets 
domain 

Network Definition File (WETWDEF). Tn€ NETWDEf file identifies trie nodes 
[computer systems} in the HP Sockets domain, giving their logical and physical 
names, hardware types, startup status, and C compiler availability [see Fig 21 
Nodes are identified by their physical LAN name and are given a logical name 
(e q. r cpul in Rg. 21 All references to a node are done with the logical name so 
that if a node is removed, all HP Sockets functionality can be transferred to anoth- 
er name with just a change in the WETWDEF file. The startup status says whether 
or not a node should be started up 

Process Definition File (PROCDEF) The PROCDEFfile lists all processes known 
to the HP Sockets domain (see Fig. 31. This file also ties a process to a logical node 
name (e.g., in Fig 3 process bokupcp is tied to node cpui \. When the user speci- 
fies the movement of data in the system, the receiving process name is used, not 
the node name. The correct node is identified using the PROCOEF data. For pro- 
cesses listed in this file that are to be started or stopped using HP Sockets, the 
user can specify a run string with parameters in the PROCDEFfile Also, execution 
information such as the user identifier and password can be kept in this file 

File Definition File [FILEDEF) The FILEDEF file lists any attributes of files that will 
be transferred using HP Sockets, This file is optional File attributes refer to the 

receiving node, and define such things as type (ASCII or binary!, record size and rf 
the existing file can be replaced Files that are not specified in this file can be 
moved using HP Sockets, provided the default file attributes used by HP Sockets 
are acceptable. 

Data Definition File (DATADEFJ This file defines the structure of the data trans- 
ported between processes or applications. This file is optional 

Data Manipulation Definition File (DMANDEF). This file defines the manipula- 
tions that must he performed on the data to make it understandable to the receiv- 
ing application. This file is also optional 



fThfl Network Befmmon file. NETWOEJ ttukJ carmen an entry far each node in tk» MP 



•This is the formal for each entry The number* in parentheses iodicite ti 

■irngiti of each field Optional item* are encloted in square bracken 

t 

•Node - Log tea INode Name Machine Type 

■ HEi 

^Startup ■ StarttipStatus; 

■ 

[Compilation Nod* 3 CompitalionNodeFteg" 

# m 

«tM«Clof>es = Ma* Clones Nombef] 

# 

*|M 31 Message Area = MaxMsgAreaSiie] 

I 

tfMaxPerPrQcess ■ MaxMsg Area Process] 

I 13. 

fNetworkTypa ■ Networking Type : Physical Node Name 

* (50? 
Node * cpul HPWttVSSOQ 

Startup =■ 1 

CompilatmnNode = 1 

MaxClones = 

MaxMessagesArea m 100 

MaxPerProcess = SO 

Network Type = LAN : hpiac9g.fip.com 

t Use Ihe nodenaiiie command Irom the shelf 10 gel this name 

i 

This is the end of the node definitions. 

Fig. 2. A porta ^ network defini!mn file (NETTWDEFI 

Link Definition File (UNKDEFI This file ties the data manipulations in the 
DMANDEF fife and the data definitions in the DATADEF file to the sending architec- 
ture, and to the sending and receiving languages. The same manipulation defini- 
tion can he used in links describing differing languages and source system types. 
This modular approach to data movement allows the user to specify more easily 
many different types of links by leveraging from a single user message representa- 
tion, Thts file is optional 

Link definitions are used to describe a specific link [data transfer) between two 
applications Each link defines the language used by the source application to 
produce the data and the language that is used by the consuming application to 
access the data Each link must also describe the format of the data at the sending 
and receiving ends of the link and any data manipulation that should be applied to 
the data 

In essence, a link definition name is used to bind the physical characteristics and 
operations that must be perf armed on data bemg transferred between two appli- 
cations. This link name is used by the sending application at tun time to invoke the 
operations necessary to get the data into a format usable by the receiving applica- 
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«The Process Definition file. PHOCOEF. must contain an entry tor each process known In the 

sHPSackets Domain. 

•This is the formal tar each entry. The numbers in parentheses indicate the maximum 

* length of each held. Optional items arc enclosed" in square brackets. 
t 

«PLN ■ Process Logic Nemo Logical NodeName [:CI one Flag! 

* (16] ITBI (II 
Hf(Exec p ExeclnlaJ 

# \m) 

¥lRun = DetaollRun Siring] 

# 12S5) 

PLN - loakupcp : cpul \ 

Exec a 100 user : passwd 

Ron = yoor home directoryAulorial/programs/loohupcp 

# 

PLN = mqcp cpul I 

Exec = 100 user : passwd 

Ron ■ your home directory/tutQrial/profjramt/mqcp 

i 

H'tngcp is the end of the process definitions. 



Fig. 1. HP Sockets conf'guraTior* files and the fields <n each file that associate one file with 
snathe* 



Fig, 3. A portion nf 3 process defiTiitFOn fife (PROCDEF) 
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Fig. 4. The mnhguratmr, validation process., 

lion At validation time, the link information is used to help generate the source 
code thai carries out the operations at run time 

Examples of a data definition file, a data manipulation definition file, and a link 
definition file are provided in "Data Mampuiatiur' on page 20. 

Changing Configuration 

Changing a configuration is a simple task performed via the HP Sockets manager. 
A configuration is changed to add nodes Icomputers} to the domain or remove 
them from it. or to alter definitions, processes, mampufations, or links The steps 
required to change to a new configuration include 
■ Modifying thn configuration files. This can be done While HP Sockets js running a 
current configuration 

• Validating the new configuration fites This can he done while HP Sockets is run- 
ning a current configuration. 

• Shutting down HP Sockets when validation is successfully completed. 

• Starting HP Sockets with the new configuration. 

Configuration Validation 

e thn mnf juration files can be used by the HP Sockets run-time modules 
they must be checked against one another for correctness, and the files containing 

• tta :leni n.cn and data manipulation definition data must be compiled The 
process to gel all this done is known as configuration validation (see Fig 4) Con- 
figuration validation takes place on the administration node ano includes the 
following activities 

• Thn validation program reads the network definition INETWDEF), process de'imtion 
(PRfJCDEFL and file definition (FILEOEF) configuration files from the usa\\ directory 

• The validation program invokes the DDL (data definition language) and DML (data 
manipulation language) compilers, which read the OATAOEFand DMANDEF files 
respectively, The DML compiler also reads the link definitions from the linkdef 
tile. 

• Code generation takes place in two phases. The first phase generates the 
perform data manipulations and occurs as each data manipulation is recognised 
The second phase occurs after all of the data manipulation definitions have been 
processed and is responsible for generating the data manipulation C source files 

• The validation program generates a catalog file which contains information about 
the fifes used for the latest validation 

Tub validated configuration files are in a format thai can be loaded into memory tu 
become the memory -resident configuration tables. 

For the cade generation process described above, one area of great concern is the 
ability to add support quickly for new languages and computer architectures. To 
aid this goal the code generator has been designed to be table-driven Two princi- 
pal types of tables are used Trie first type describes the physical representation of 
the data types for a specific language on a specific architecture and The second is 
used to describe legal type conversions between data types and the functions to 
call to generate the code to perform the type conversions. 



If communication fails because of a connection failure, 
the Onmc process notifies its child process Onmh (outgoing 
network manager helper) to begin trying lo del eel when 
it is possible to communicate with Ihe node again- The 



Onmh, in turn, notifies the Onmc when lo try to communi- 
cate with i he node again. The Onmc sends t lie spooled 
messages when the cause of the network service failure* 
disappears and the Onmc can successfully establish a con- 
nection to Ihe node 

I lif Onmc spools messages destined for different nodes to 
Hie same spool file, rather than maintaining a spool file 
for eacll node. This is done primarily to save file deSCrip 
tors lor connectlOJtts The spool file is segmented into file 
blocks. A file block is associated with a node and all file 
blocks belonging n> oiie node are linked together. Mes- 
sages, including spooled messages, are always sent lo a 
node in ihe same order in which they are received. 

HP Sockets Management Daemon 
Tin* management of IIP Sockets across various nodes 
linked by a DAN requires the existence of a daemon pro- 
cess on every node, which is responsible for performing 
the various management tasks on that node. This daemon 
is called the MP Sockets management daemon, or SMD. 
The attributes of the SMD Include; 

• Providing support lor die HP Sockets functions on a node 
in the HP Sockets domain 

• Remembering the steps of any task performed so lhal 
they can be undone if requested or if the network connec- 
tion to the requester is lost 

• Supporting a wide variety of" requests from ihe IIP Sock- 
i is manager {'amain ) on any node 

• Providing extensiblitv for future requirements 

• Supporting requests from various nodes simultaneously. 

The HP Sockets management daemon, as its name im- 
plies, is designed to run in the background and disassoci- 
ate itself from the login session. It uses a slight variation 
of the approach suggested in reference - 

The SMD is also responsible for scheduling Ihe IIP Sock- 
ets programs on the local liCXte, For example, in the HP- 
UX environment some of the programs need To be sched- 
uled as the HP Sockets user (hpskts) while others need to 
be scheduled as the root user. To accomplish lias the SMI) 
i^ uself scheduled as root. It then switches itself to being 
an hpskts user. This sets its real user i dent i Her and its ef- 
fective-user identifier lo hpskts and its saved-user identifier 
to root. So now the SMD can switch itself between an 
ef fee live-user identifier of root and an effective-user identi- 
fier of hpskts as needed. 

When the SMD is scheduled it also starts the eiror logger 
program arid the file transfer daemon. II monitors these 
programs because they are critical to the operation of HP 
Sockets on thai node. If either program fails then the 
SMD Stops all activity m the node and shuts itself down. 
The SMD always keeps track of the current status of the 
by saving status information in an internal variable 
called Node State, This information can then be made avail- 
able to any HP Sockets program that requests it. 

Some of the requests that the SMD supports are mutually 
exclusive (e.g., Ihe HP Sockets manager functions startup, 
shutdown, and switchadmm i Such requests are called major 
requests. Other requests like nadestat can be made at any- 
time on any node. To control the major requests on rhe 
node, the SMD maintains an internal flag called the Major- 
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RflquestRag. When an IIP Socta mi wants to i 

Ete a major request, it first attempts 10 se? this flag 
before proceeding with the request ttsett Information 
about the major request currently being executed on the 
nodt parate global variable called MajarRe- 

quest. The MajorReQuest variable also k< ni~ the 

com ' which this request Ls made. The SMD uses 

this connection and other factors to identify who has con- 
trol of the MaiorReqiiBstFlag. 

The unary tas Me local ■ re- 

qm the HP E manager (see below). The 

SMD sets up a network call socket on which it can re- 
ceive a connection request from the HP Sockets manager 
After accepting the connection request, the SMD ?> ates a 
virtual connection to the HP Sockets manager. This eon 
nection is left open until the HP Sockets manager decides 
to shut it down. \l the connection is lost lor any reason 
then the SMD reverses the steps taken during the request 
and clears the MajorRequestFiag (if it was set hv (he HP 
Sockets manager on the lost connection), 

' >ii- ■■*• ,i connection has been established to the IIP Sock- 
ets manager, the SMD processes the requests sent by the 
HP Sockets manager The reply to the request will depend 
on the request itself and the success or failure of the 
SMD in executing the request. To facilitate the communi- 
cation, the SMI j lias a well-defined message buffer thai it 
transmits across the network. This buffer is used hy all 
IIP Sockets programs that want to communicate with the 
SMD. 

Another function oi the SMD is to help expedite certain 
requests, especially I he startup of nodes across the IAN, 
tine way is to have the SMD copy (i.e., pull) the files 
required by its node rather tlian have them copied ( i < 
pushed J hy the IIP Sockets manager. This approach also 
gets around the need for the IIP Sockets manager in have 

special permissions to do the push. 

Fig. shows a simplified Illustration of the connections 

between the IIP Sockets manager and its local SMD and 
some remote SMI is. 

HP Sockets Manager 

The IIP Sockets manager program (smain) is the main 
administration component of III* Sockets. It can be run 
from any node in the IIP Sockets domain. The HP Sock- 
ets manager is used by the system integrator for creating 
an integrated system and hy the system administrator to 
manage the integrated system, The HP Sodkets manager 

uses passwords in guard againsi unauthorized act-ess. 

The primary tasks that can be performed ' 

administrator through the IIP Sockets manager commands 

are: 

• Stalling up and shutting down I lit- system from the ad- 
ministration in nil 

• Establishing a security scheme for the system from the 
ad n ii n i s t ra t i o I 1 nod e 

• Responding to errors recorded in the error log file by HP 

Sockets from any node 

• Customizing the < nor log files <<* meet system heeds from 
any rtocte 

• t In (king status of the HP Sockets domain from any nodt 1 
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Fig, 9, Connections ■ t the HP s 

SMI 'and remote SMI is. T itus and re- 

quest rjtats 

• Su itching adininistration capability from 0p$ node to 
another from an administration or alternate administra- 
tion node 

• Changing HP Sockets parameter values from the admin is 
nation node only. 

Switch Administration. The switch administration (switchad- 
min) fimeiion of the HP Sockets manager was treated so 
that the major IIP Sockets administration functions won Id 
not lie lost if the administration node is unavailable. 
There ean only be one administration node m an HP 
Sockets domain of nodev However, any of the Other 
nodes may he designated to he alternate administration 
nodes, Aliemaie administration nodes are the nodes in 
the IIP Sockets domain that are able io take on the title 
and dilutions of the administration node. This is done 
using the switchadmin function on the alternate adiuinislra 
feion node, 

When the user invokes the switchadmin function, the Joenl 
IIP Sockets inaiingenieni daemon (SMD) is contacted for 
status information, The SMI) returns status ahoui the lo 
CaJ node, and a check is done lo see whether the node 

requesting the switchadmin is an alternate administration 
nod, 

The switchadmin first tries to make a network connection 
with the SMI) on the current administration node. It then 
svnds a message m that SMD telling it to switch itself 
from an administration to an alternate administration 
node. This Mulch involves updating internal variables in 

tin' sMh that contain the administration stains, and the 
logical and physical names of the new administration 

node, \e\l, the switchadmin module connects lo ils local 
SMI), sending a message telling it to switch itself to in 
administration node This also involves updating the same 
SMI> Internal variables. Finally, alter the old and new 
administration nodes are in synchronization, a lisi i 
Created containing all die Other nudes configured in the 
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current EIP Sockets system Connecticms are made to the 

SMDs on these timl^.s, and messages afce wvA informing 
i J i' m' SMDs of the new administration nodes logical ami 
physical nanu\s. 

If one or more nodes are down when a switch 8dm in is 
done, they can be resynchrunitfetl later by rerunning tfte 

switchadmin function from the administration node- 

Node Status. The HI 1 Sockets manager node status func- 
tion (nodestat) gives information on one or all of the nodes 
edlrfigured in (lie current HP Sockets domain, or in anoth- 
ei as yet tins&rted domain whose configuration files are 
in a user-specified directory, 

Nodestat makes a connection with the SMD on cacti node 
from which it is obtaining status information. The SMD 
on each node retrieves the stalu.s information from its 
ii in nitil variables, and sends if back to the requesting 
process. Typing nodestat at the IIP Sockets manager 
prompt wilt give information about the local nodi*, and 
typing nodestat <node logical name> gives information about a 
particular node. Typing nodestat* will list information 
about all nodes. 



The information shown for nude Mains includes: 

• Logical ri; 

• Physical name 

• Run-time status (running or stopper] | 

• Administration class (administration, alternate adminis- 
tration, or nonadminisi ration 

• Machine type 

« Administration node logical name 

• Administration node physical name 

Security- Tbe IW Sockets manager security function al- 
lows the user to add and delete user names and pass- 
words lhal are required 10 aoress ihe IIP Sockets manag- 
er The allowable commands for the security module are: 

• Add, Add a user name and password to the user lite 

• I >Hek\ Delete a user name and password from the user 
file 

• List. List all user names in the user file. 

The security file is disseminated to all the nodes in the 
domain at startup and alter eaeh update. 



Performance in the HP Sockets Domain 



Since it js impossible to predict the performance of HP Sockets for alt possible 
configurations, some results are presented for severe! example test configurations. 
These tests represent typical configurations in which HP Sockets operates De- 
scriptions of factors contributing 10 performance results are alsu given. 

Test Configuration 

The system factors affecting HP Sockets performance include the CPU type, oper- 
ating system. LAN activity, and network conf iguration. Tests were performed 
between HP 9QO0 Series 30D and Series 800 computers connected by a LAN. All 
systems used the HP-UX 7.0 operating system and comamed 16 megabytes of 
main memory All tests were run on an isolated LAN link. Except for virtual memory 
daemons, no other system processes were running during test execution Fig 1 
shows Three sending adapters and one destination adapter running on separate 
nodes All messages were directed to a single destination adapter and both nodes 
were sending and receiving messages concurrently through HP Sockets. The mes- 
sage transit lime between two adapters was estimated by measuring the time to 
transfer a large batch of messages (typically 5DQ0 rnessegesl ueiween each send- 
ing and destination adapter pair The message transit time was calculated as the 
time difference between the first send and the last receive, divided by the batch 
size File transfer time was measured usmg the same method- Also. CPU utilization 
and the number of LAM packets going across the network were momtored while 
the Jests were executing, 

For the setup shown in Fig. 1 . each sending adapter sent messages as fast as it 
could. The overall sending rate was increased by increasing the number of sending 
adapters. For stress tests, 96 sending adapters were successfully tested 

Performance Results 

Some of the oro duct-specific factors that affect the performance of HP Sockets 
are 

• The sending rate (in Fig. 1 , the number of sending adapters) 

• Whether delivery is with wait or without wait 

i Whether delivery is guaranteed or not guaranteed 

• The sm of The message or file 

• The data manipulation required for each message, 

Message transfer times were studied for message sizes of 64, 256, 768. and 1024 
bytes. HP Socket's maximum message size is s024 bytes. The maximum file size 
tested was one megabyte 




HP 3000 Series 300 or 800 



HP 9QO0 Series 300 or 800 



LAN 



Fig. V fe$ mrifigu'a'icn fer perl or ma nee tests. 

A sending adapter can deliver a message with or without wait. When delivering 
with wait, the sending adapter does not continue until it receives an acknowledg- 
ment from the destination node. Therefore, the time for a round trip occurs be- 
tween each message sent. In contrast, when a sending adapter delivers a batch of 
messages without watt, it can send messages at a higher rare. 

The throughput is faster For a batch of messages delivered without wait In fact, if 
the systems are not heavily loaded, delivery without wait can double the through- 
put. If the systems are heavily loaded, the increase in throughput may not ha 
noticeable. 

Similarly, a sending adapter can deliver a message with or without guarantee. 
Messages delivered with guarantee are written and flushed to a disk file; thus two 
disc accesses {a write followed by a read! are done tor each guaranteed message 
transfer. In contrast, messages delivered without guarantee are kept in shared 
memory Guaranteed message delivery requires more system resources (CPU and 
disk 1/0). However, the total message transit ttme may be unaffected, unless the 
systems have extremely high I/O activity. 
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Fig. 2. HP Sockets file transit nme as a function of file sue using an HP 9000 Series 37D 

Fig, 2 shows the performance for file transfer between two HP 9000 Series 37D 
CDrrspuiers. File transfer time for a small file (less tnan 10 kilobytes) is about 600 
milliseconds. Rle transfer time increases witfi file size — from about 0.6 second for 
a 10-kifotiyte fi'fi to about 4 seconds for a one-megabyte file. 

Fig. 3 shows the message transfer time as a function of message size. Again two 
HP 9000 Seres 37D computers were used. The data in Fig, 3 was generated for 
delivery without wait and without guarantee, but tests with wait and with guaran- 
tee showed results that were only slightly higher The line labeled "No Data Ma- 
nipulation"' stiows the results for messages sent wiificut data manipulation Since 
these messages were transmitted directly to their destination, the transfer time 
was fast and showed tittle dependence on the message size. Even far the maxi- 
mum-wed messages, transfer time without data manipulation was always less 
than 22 milliseconds 

The line labeled "Host Data Convened" is for messages that required simple data 
manipulation Message transfer time mict eased with the message size to about 70 
milliseconds for large messages. The line labeled "Extensive Data Manipulation" 
is for messages transferred with extensive data conversion. In these tests, an 
array with elements of type integer was converted to an array with elements of 
type real For example, a message size of 1024 bytes required 25B mteger-to-reaf 
conversions Under These conditions, transit time was always under rOO millisec- 
onds 

Performance tests For HP Sockets are conducted continually under many environ- 
ments and conditions. The results given here represent a typical environment, 
consisting of a single sending adapter and a single destination adapter, each on 
separate nodes, sending a large batch of messages If CPU and/ or LAN loading is 
normal, these results represent a conservative estimate 
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Fi§. 3, HP Sockets message trans/t time ds a function of message s/e using two HP 300Q 
Series 370s. 



Startup and Shutdown 

The startup of the HP Sockets nirt-time programs on the 
various nodes connected t>y a LAX poses some interesting 
problems. It is necessary to distribute the configuration 
files to all the nodes in the network that need them and 
to coordinate the muEtistep startup sequence concurrently 
on all the nodes. At the same time, the startup sequ> 
mus ihle enough to allow the user to back cm 

ihe startup sequence at any rime A further requirement is 
the need to abort the startup automatically if a major 
catastrophe occurs, like the loss of the connection be- 
tween the startup program and the local SMIX Addittonal- 

I he number of nodes that need to be started can far 
exceed the system limits on the number of open connec- 
tions that any process, like the IIP Sockets manager, is 
allowed to have. This section outlines how these prob- 
lems were solved and Fig. 10 shows some of the data 
flows between the administration node and a nude in- 
volved in the startup process. 

All network connections are established using a connec- 
tion-oriented protocol, such as TCP/IP. 3 Once a connec- 
tion has been established. I lie HP Sockets manager on the 
administration nude, uirh The help of the local and re- 
rnote SMUs, keeps ihe connection open until all the steps 
in the startup sequence are completed. The design of the 
SMD allows the HP Sockets manager to request that the 
connection to a particular node be temporarily relin- 
quished, I hereby suspending the startup process on that 
node before the sequence is finished. The SMD can also 
aiiinm;iii( ally undo the startup sequence on a node if the 
network connection between the SMD and the HP Sock- 
els manager is lost before the entire sequence is don 

Before beginning a Startup Sequence, six configuration 
files ntusi he validated (see "Configuration Files* on page 
1:1). Configurai ion file validation converts the tiles to a 
formal that allows them lo be loaded into memory. Once 
Ihe eunfiguralion files have been validated, the user in- 
vokes the startup command from the UP Sockets manag- 
er screen, and specifies (among other things) the directo- 
ry path to the validated configuration files to he used for 
the startup, 

The IIP Sockets manager connects to ihe SMD on Ihe 
local node and sels Ihe MajorRequestFlag maintained by the 
SMD to ensure that the node is not interrupted during the 
startup sequence. This network connection to the lucal 
SMD is never relinquished for any reason, II ihe connec- 
tion is lusi then the Startup sequence is aborted on all 
the remaining nodes and an automatic cleanup is per- 
fornietl hv ihe SMD on each affected node. 

After setting the MajofRequestRag, the HP Sockets manager 
requests the local SMD to report on the cm rem status of 

The loe;il node. The IIP Sockeis manager then verifies 
that the startup request was issued from ihe adiiiinistm 
don nude, and if nui, the startup sequence aborts. 

•There can fee mare than one sat of validated configuration files, Bach in a different direc- 
tory 
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If the user has specified a new configuration Ele directory 
in the Startup rail, the IIP Sockets manager copies the 
configuration source files and the validated configuration 
files to its working directory (® Fig. 10). The IIP Sockets 
manager (hen requests the SMD to load a copy of I he 
validated configuration files into local memory, creating 
the run-time configuration table (2 in Fig. 10). The start- 
up program extracts configuration informal ion honi this 
table to build a singly-linked list (called the domain node 
list) containing all the nodes Ihat are configured in the. 
IIP Sockets domain ( 1 in Fig, 10). This lisl enables the 
startup program to coordinate Ihe network-wide startup 
of all the nodes by keeping (rack of each node's status. 
While the domain node list is being built, a list of com pi- 
lation nodes is also created, 

Compilation nodes are nodes in the IIP Sockets domain 
that deliver and create (via V compiles) data manipulalion 
modules for specific machine architecture groups. For 
example, one of the HP 9000 Series 300 machines in ait 
HP Sockets domain would be designated for compiling 
and distributing data manipulation modules to other Se- 
ries 300 machines in the domain. The same would be true 
for each of the other machine architecture groups (IIP 
WOO Seiies 800, HP 3000 Series 900) in the domain, See 
"Data Manipulation'' on page 20 for more about fl;iia m;i- 
nipulation modules. 

After the lists are built, the HP Sockets manager connects 
to the SMI) on each node that has been designated h\ 
the user for startup. If it cannot establish a connection to 
a node in three tries, startup on that nolle is aborted and 
the domain node list is updated. The connections are all 
established in parallel. When the IIP Sockets manager 



runs out of nodes to be connected to or cannot make any 
more network connections (because of system or process 
touts) then it waits for responses to come back em the 
connections that have been established. 

To reduce the time required to start up all the nodes in 
the domain, files are copied (pulled) by the SMDs on the 
respective nodes, 

The HP Sockets manager uses a connection management 
table to keep track of all the remote SMDs to which it is 
connected at any time. The table is an array of pointers 
to the corresponding nodes in the domain node list. The 
status of Ihe network connection from Ihe HP Sockets 
manager to the SMD on a remote node is kept in die 
appropriate list element. For example, whenever the star- 
tup process is aborted on a node (for whatever reason) 
the domain node list is updated accordingly 

As a response is received on a connection, the HP Sock- 
ets manager processes that response and posts the next 
request fin the shirt up sequence) to that SMD. If there 
are nodes rliat did not get a chance to perform the cur- 
rent step in the startup sequence because there were no 
more network connections available to the IIP Sockets 
manager at that time, then the node that just replied is 
temporarily disconnected from the IIP Sockets manager 
The HP Sockets manager then connects to a node that is 
behind in the startup sequence and posts the current re- 
quest. This approach is followed for each step in the 
st h itl up sequence. Only the connection to Ihe local SMD is 
never relinquished. If there are no nodes Ihat are behind 
in the startup sequence then the next request in the se- 
quence is posted to the node that just replied. 
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Node List, and Nodes that Need 
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The IIP Sockets manager asks the SMD to set the Majorfle- 
questFIag on that node. (If the flag cannnt he set then the 
startup ] ted on tha* node.) After setting The 

MajorRequestRag, Ihe HV Sockets manager asks the S\ir» u> 
report on the current status of the node. The startup se- 
quence vsill tie halted on a node if the machine type does 
not match the machine type coj or The run-time 

programs are running but with a different configuration 
identifier from that used in the startup 

The IIP Sockets I - hecks to sec :;aa ma- 

• lies need T " be built for any of the nia- 
chine architecture groups in The configuration* if a data 
manipulation module needs to be built fox a given 
rlii- . t oi|> then the HP Sockets manager 

connects to Ihe SMD on The compilation node for that 
machine architecture group. It requests thai the SMD 
schedule the data manipulation module builder. The HP 
Sockets manager then communicates directly with the 
data manipulation module builder and requests a to pull 
the relevant C .source file from the administration node 
', ' in Fig. II). Then a List of nudes (Of thai machine ar- 
Chitecture group) that require data manipulation modules 
Is supplied to the data manipulation module builder ( ?■ in 
Fig. 11). For each node thai needs a manipulation mod- 
ule, the builder 

Compiles the appropriate C source files (3 in Fig. 11) 
Builds the data manipulation module 



Administration Node 



Compilation Node 




Fig. 11. Activities \uk\uy pte* between the admlnistfiitiori node and 

a (■(mil ■;!..! rii node during startup and mi- en :i r n m ■■■! dai a ruiiriipiilu- 
tinu modules 



* Distributes the ttata manipulation module to the node by 
requesting that the SMD on that node pull it < n 
Fig. 1 1 

i he data manipulation module builder completes the 
task fnr a given node on the lisi il reports the status 
hack to the IIP Si the data mampui 

Chile cannot be bull! for a given node Then that ti" 
not starterf 

After finishing w ies. the HP S 

sMDs on the other nodes to pull 
tin' s in Fig. bo required to 

build the memory-resident run-time configuration table on 
thai node. Once this step has been -tally accom- 

plished die SMD is asked to prepare the run-Time pro- 
grams on that node for startup. All these Steps are per- 
formed on ieada node fa the sequence indicated hm are 
done iti parallel on all the nodes. 

Once the run-lime programs have been prepared for si art 
up on all the nodes designated b> the user (and did not 
fail any of the steps outlined above), the user is asked it 
the startup Should proceed or be aborted. The users deci- 
sion is eommunieaied to the SMD daemon on all the 
nodes wailing lo Mmi. 

When these steps in The startup procedure are complete,!, 
Ihe SMD on each node is told to transfer (i.e., pull) the 
security tile lVnm the administration muh^ i - in Rg. LO) 
so that all nodes in the domain have the same security 

Hie. 

The user is allowed to aboil the startup process at nr i \ 
lime except when the configuration files are being trans- 
ferred Ironi the user's director; tq the IIP Sockets work- 
ing director^ and when the data manipulation modules 
are being huill mi the various compilation nodes, IT the 
IIP Sockets manager decides lo abort th« Startup S€ 
quence on any node for whatever reason, then the steps 
ihai were accomplished so far on that node are undone 
by the SMD on that node and ihe si an is of fee node is 
relurncd to fts preslarlup state 

If the node thai is being started already has the latest 
configuration files available from a previous startup, I hen 
some of The steps listed above are omitted This signifi- 
cantly speeds up the startup process. 

The user ean shut down HP Sockets from the IIP Sockets 
manager screen on the administration node. During shut- 
down, the HP Sockets manager uses an approach that is 
very similar to that used during Startup, It goes through 
the same sequence of firs! setting the MajorRequest Flag 
held by the SMI J oil the local node. After cheeking the 
StatUS i*t" Ihe lr>e;il ttQde H connects Id the SMDs on all 

ihr nodes feat need to be shut duwit 

< '!iec the SMDs on all the nodes marked for shutdown 
have been a 1 cited m (he Impending shutdown, the user is 
asked il the shutdown should proceed or be aborted. The 
user's decision is eommunicated to the SMD on all the 
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HP Sockets Gateway 



The HP Sockets Gateway product uses a client/server model to extend HP Sockets 
capabilities to machines not using the HP-UX or MPE XL operating systems. The 
client is a user application running on a machjne such as an JBM 3090 mainframe 
or a PC The server is an HP Sockets adapter (called a server adapter) running on a 
gateway nade r which is an HP-UX node within the HP Sockets domain that has 
been designated to run the gateway server. 

The gateway server maintains a network connection to one or more client applica- 
tions running on the client machine. Every gateway node has one server daemon 
(pf each networking sen/ice; it create? server adaptors required by the client ap- 
plications. The server adapter provides the functionality of HP Sockets to a client 
application. It is also called a virtual adapter since it acts on behalf of a client 
application. 

An application on a client machine is linked with the client HP Sockets access 
routine library. This library lets a client application send or receive message or file 
data to or from any other processes within the HP Sockets domain. The parameter 
list and return values far this library are the same as for the HP Sockets HP-UX 
access routine library. Functional differences between the client access routine 
library and the HP Sockets HP-UX access routine library have been minimized 

The current release of the HP Sockets Gateway uses TCP/IP for interprocess com- 
munication across the network and ftp (file transfer protocol) for file transfers 
Currently software is available far connections to an IBM 3090 mainframe running 
the MVS operating system, or a PC running MS-DOS. 

HP Sockets Gateway Components 

The HP Sockets Gateway components consist of the server daemon, the server 
adapters, the client HP Sockets access routine libra ry, and the client applications. 
Fig. 1 shows the server daemon and three server adapters running on the gateway 
node, MachineA. The dotted lines in the figure indicate that the server adapter 
processes ere child processes of "he server daemon process Each of the three 
server adapter processes services a client application The node labeled MacrnnaB 
could be a PC running MS-DOS The node labeled MachinaC could be a mainframe 
i«e the IBM 3090 system. 

The purpose of the server daemon process is to accept connection requests and 
create server adapter processes The server daemon is always active, ready to 
create multiple server adapters when connection requests are made It listens at a 
well-known part numher associated with the HP Sockets Gateway service. The 
client applications make connection requests to the server daemon through the 
gateway service via access routine library calls. 
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Fig. 1, A server daemon and three server adapters running on the gateway node 
1 Machine A}. 

Each server adapter is associated with an HP Sockets logical process name. Since 
a server adapter is a virtual adapter, this logicat process name is also the effective 
logical orocess name of its client. The logical process names are entered in the HP 
Sockets process definition file [PROCDEFJ, described in "Configuration Files'" on 
page 13. 

All access routine library calls are serviced by the server adapter on behalf of the 
client application. For example, when a client calls the access routine SpReadQ, a 
message is sent aver the gateway network connection to the server adapter The 
message contains all the parameters of the SpReadQ access routine call. The 
server adapter then issues an SpReadQ call to HP Sockets using the same parame- 
ters. When the SpReadQ call completes at the server adapter, it returns the output 
parameters and return codes to the client application. Except for the Spin it routine, 
all calls to client library access routines are handled tne same way 

When a client issues a call to Spirm for the first time, a new server adapter is 
created, When the Splnit call completes successfully, the client has a virtual con- 
nection to a dedicated server adapter, and through it to HP Sockets 



nodes wailing to shut down. The user is allowed to abort 
fche shutdown process al any time- 
Using a single control point for startup and shutdown of 
the entire IIP Sockets domain relieves the user of the 
obligation to start and stop each communicating CPU 
indivi dually. In addition. IIP Sockets automatically distrib- 
utes all control information lo designated alternate admin- 
istration nodes to prevent (lie single control point from 
being a single point of failure. This prevents undelivered 
messages from being lost or processes from hanging on 
imfuin liable reads. 



Data Manipulation 

The data produced by one program may not be usable by 
a different program because the selection of elements in 
that daia is not what the receiving program expects. Less 
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obvious is the problem of the basic data element types 
not being readable by a receiving program either because 
the sending and receiving programs are written in differ- 
ent programming languages or because they reside on 
machines that have different architectures. 

The same data type passed from one program to another 
can have a different format in each program if the pro- 
grams were written in different programming languages. 
The same data type sent and received between two pro- 
grams written in the same programming language can 
have different formats if the two programs were compiled 
on different machine architectures. Not only can the dam 
lype formatting be different when programs reside on 
different machine types, but the data type sizes and align- 
ments (address locations used in memory-) can also be 
different between the rwo programs. Most of these differ- 
ences are because the language compiler optimizes the 
code by taking advantage of (lie data type et'fn irneies 
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and sizing that the underlying machine architecture pro- 
vides. 

A brute- force method of dealing with data type format 
and language -to-machine incompatibilities is to write spe- 
cial conversion routines con vetting data types from lan- 
guage A on machine type B to language C on machine 
type D, These conversion routines would grow in number 
and complexity with the addition of each new language 
or machine type supported The amount of conversion 
code would eventually become unwieldy and difficult to 
maintain, Another drawback is that one would have to go 
back and add code to already supported machines to sup- 
port the new language or machine type. 

The IIP Sockets solution to this problem is twofold First, 
IIP Sockets uses a standard, common way of representing 
values for a particular data type independent of the 
source or target language and machine type. This is 
called common data representation, or CDR. Secondly flic 
application-specific manipulation is done only on the 
sending machines. Fig. 12 provides a simplified illusi ra- 
tion of w r hat happens when a data structure from applica- 
tion A is manipulated io be compatible with the data 
Structure required by application B, which is on another 
node. Note tli?ii ChR conversion is done on both nodes, 
but application-specific manipulation is performed only on 
node A, the sending node. 

Common Data Representation 

Implementation of the common data representation for- 
mal on any system in the IIP .Sockets domain requires 
I wo sets of conversion routines for each language sup- 
ported for that machine type: one set to convert from one 
local language into CDR and another to convert from 
CDR back inlo thai I'xnl language, doing fro in a locnJ 
language to CDR is called marshaling and going from 
CDR to a local language is called unmarshaling. A big 
advantage of this method is thai us new languages and 
machine types are added h> the network, cod*' changes to 
support tin- new languages or machine types are isolated 



Fig. 12, A simplified illustration of 
the data manipulation, marshaling, 

and unmarshaling of data in the 

HI- 1 g ■ .nain. 

The Basic Encoding Rules fBER) of Abstract Syntax No- 
tat ion One ( ASN.I } 4 - J were chosen for the format of the 
CDR data types. ASNJ is an OSI (Open Systems Intercon- 
nection) standard thai specifies the different types of data 
structures that can be transferred between protocol layers 
of art OSI stack. The Basic Encoding Rules define die 
encoding and decoding rules for these data structures. 

As shown in Fig. 12, the target information is marshaled 
and sent with the CUR data so that the receiving side can 
umnarshal and localize the CDR data appropriately, Thus, 
the CDR data is self-describing for eventual unmarshaling, 

ASM! does not make the CDR data completely sell '-de- 
scribing. For example, ASN.I allows murshaling an integer 
into a generic representation. That integer will eventually 
be unmar shale d into a localized integer data type. The 
problem is in determining which local integer data type to 
convert the CDR data into. If the local language is t\ the 
CDR integer could be converted into either a short inte- 
ger integer, or long integer data type. The target data 
type to use is specified by the user through data defirm 
lion declarations made via the data definition and data 
manipulation languages, or DDL and DML respectively. 
These languages make up the application specific manipu- 
lations shown in Fig. 12, 

This extra, self-descriptive information is called type at- 
iributcs. For example, the ASN.I string type encoding 
indicates the eurreul size of the string but not the maxi- 
mum size ir should be on (he receiving end of the trans- 
fer. This maximum size is included with I be CDR data 
and is a type attribute, 

Because of lite complexity of the task of data mampula- 
lion and I he need for the best performance possible, 
there is tight coupling between the CDR marshaling and 
unmarshaling routines and the HP Sockets-generated data 
manipulation code that calls them. Thus, the CDR rou- 
tines cannot be used apart, from the rest of the product, 
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struct! 

char Ope ralor[20]; 
m J Month; 
inr Day. 
iirtVear; 
Hd; 

(*) 

DATADERNITIOK 



itniefl 

char Dp*r»lorfl5]. 

charDalefltl: 
If): 

{la 



f* Define structure <rf as i record named 
input data in DDL*/ 

inpui_data = RECORD OFI 
Operator • STHING[20] 

Month : INTEGER; 

Day : INTEGER; 

Year INTEGER 

.■" Define structure rl as a record named report! in 
OUl'f 

r&porll ^ RECORD 0F[ 
Operator STRINGl15J; 

Month : ARRAYED OF CHAR; 

Stash! : CHAR; 

Day : ARRAY(2| OF CHAR; 

CHAR 
: STRING[51; 
L' 

10 
r The formal of Ihe Out a Manipulation Definition lile iDMANDEFJ is shown below, 

DEFINE MANIPULATION Manipulation Name; 
SOURCE DATA : SourceDalaSlructureNarm-', 
DESTINATION. DATA : DesrinationOataStruCtuieName; 

BEG IN .MANIPULATION 
<manipulation slalemcnts>; 
END MANIPULATION: 

7 

DEFINE MANIPULATION! m reflOftt: 

SOURCE DATA ! input. data; 

DESTINATION. DATA repcrtl; 

BEGIN MANIPULATION 

MOVE inpul_data TO report! ; 

raportl.SiashV/:' 

raportl.SlashZcV;' 
END .MANIPULATION; 

(d) 

Fig. 13, An example of de fining a iiunivne-tii-ASf]] i iii\ -n,, on in 
DDL. (a] Qri^nalstraetUFe ;,, ^me sending applie&tiaa (M Struc- 
ture in which the op^r.n- -r and date uih-mann-i will I \i>i in the 
receiving aiiplirarirpn.Ci:} DDL (JefirdtiGP fpi tht iv\-.. vrin nir-.s. (il) 
Data manipul.ji foil definition for moving the ilala in a data struc- 
ture [ike injwui lists to 'In- stru< toe defined In report!. 



Data Definition Language 

Data definition means defining I he format of the data 
transmitted between processes or applications. IIP Sock- 
ets uses these da! a definitions along with the data manip- 
ulations defined via the data manipulation language to 
manipulate the source data so that its formal is under- 
standable by the destination process. 

These data definitions lor HP Sockets are written in the 
data definition language (DDL), which is a high-level lan- 
guage for specifying the format of the data exchanged by 
processes. The DDL is used to describe the type and 
Structure (logical layout) of data produced and consumed 
by applications. A data definition is independent of any 
particular computer languages or machine architecture's 
physical representation. 



The DDL serves I he function tit a presentation layer simi- 
lar to that of ASNJ in lite < 'SI Reference Model. Howev- 
er, unlike ASN.1 T whose primary purpose is to describe 
how data is represented while in transit across the net- 
work independent of language or machine architecture, 
the DDL is meant to describe how data should be repre- 
sented at. the end points of the communication link — the 
j implications. 

This functionality is needed in heterogeneous computing 
environments because different computer architectures 
and languages represent lite same information in different 
ways (see Figs. I3a and 13b). Without a description of 
the data, there would be no way to correct the data for 
the representational differences between differing comput- 
er architectures and languages. 

The syntax chosen for the DDL is similar to thai of other 
high-level languages, such as C or PASCAL. A lex/yacc- 
based compiler is used to compile the DDL source file 
and to produce an in-tnemory symbol table. This symbol 
table is used later to drive the code generator which pro- 
duces the C source files that perform data manipulation 
and conversion to a common data representation. Fig. 13c 
shows the DDL declarations required to describe du 
structures defined in Figs. 13a and 1 3b 

Data Manipulation Language 

As mentioned earlier, data types and data organization 
may differ between source and destination nodes. There- 
fore, the manipulations that must be performed on source 
data so that it becomes the destination data must be de- 
fin ed . Manip u I at i ons rcqu i re 1 1 i e f 1 e f 1 ni t i o n o I' 1 1 te source 
and destination data contained in the data definition file. 

Data manipulations are described using a high-level lan- 
guage called the data manipulation language (DML}. This 
language allows the systems integrator to specify how to 
transform the data produced by one application su lhat. it 
is more acceptable to another application. Standard trans- 
formations include the ability to reorder the Gelds in a 
data structure, delete data fields that are not needed by 
the consuming application, and add* and initialize new 
data fields not provided by the source application but 
needed by the destination application. Fig, 13d shows the 
DML statements that define how to move and manipulate 
data coming from a data Structure like thai defined in the 
input_data record shown in Fig. 13e to the reporti record 
shown in Fig. 13c*. 

In addition to manipulating the structure of the data, ra 
pabilities have been provided for automatic type conver- 
sion and resizing of data fields. For example, converting 
an integer into an ASCII string, an integer to real value, 
or a short integer into a long integer. 

As with the DDL, the DML source file is compiled using a 
lex/yacc -based compiler* However, code generation is posi 
poned until a data manipulation lias been completely rec- 
ognized and checked for semantic errors. 
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Dam Manipulation Module 

The DDL and DML specifications created by the user 

i up in the user-defined configuration illrs.The user 
also indicates the programming language of the sending 
and receiving applications for each manipulation or data 
definition in the link definition file (see Fig. 14). This 
information enables IIP Sockets to provide automatic con- 
version ' languages — for example, con- 

K< >RTRAM twcHJimeBsionaJ array (stored in 
umn-major nrden into a ( two-dimensional array (stored 
in row-major order), or a C string kilo >* Pascal string. 
The languages current] rtfid in HP Sockets are r. 

FORTRAN, Pascal, and COBOL. Before HP Sockets is 
started up, these files are compiled via DDL and DML 
compilers info < source files and then the C files are 
compiled inii» exeetsiahles called data manipulation mod 
ales. These data manipulation modules are placed on the 
machines where tlie> will be used. Tonfi juration llles and 
the creation of data mampulntinii modules are described 
on page 13. 

Tlu dala manipulation module eliminates the need for a 
Sending application to he knowledgeable aboul the data 
representation required by the destination application. 

Fig. loa shows the values assigned to a data structure 
like that shown in Fig. 13a hy a sending application, and 



#The Link Oefimiion tile, UNKDEF, contains HP Sockets Fink definitions. 

I 

ttJhis is Hie format lor each entry. The numbers in parentheses indicate the maximum 

Slenglh of each held. Dpi ion a I items are enclosed in square brackets. 

Link = LinkName-M ■ MartipName I D a DalaOelName I NULL 

# 116} MS) |16| 
= SmirLi:L,4i»uuri[j^ = Kh i u re: <r L Etnq iirit|4J J 

I 

*[S0Ufc»Fil«D«f = SQiiff^rikD c fN,irnE! I DFFAUU] 

i m\ 

4[DesTLiii^iiAgc = D&stLanguagtt] 

R 

flDejlFileDeUOcilf ileOelrJaiiic I DFFAULT I 

# I TBI 
ifSourceNarftD=SoijrccNodoN3iiic(.St)iirt<:NndcN,'inii>]ISitufCL'Niidc%,imc) . f\] 

W H6I IT6I 

Link = linkT:M = t to rennrtl 
Source Language 1 - C 
Dc!>l Language = C 
Source Nome = cpuT 
I 
*This is the end of the link definitions. 



Fig, 14. Link definition Sle for the raanipulation (k^si ribed n 
Fig [3d 
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Fig. 15b shows the printout from the recerving application 
after data manipulation, 
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Rigorous Software Engineering: A 
Method for Preventing Software 
Defects 

Formal specification languages enable software engineers to apply the 
rigorous concepts of discrete mathematics to the software development 
process. 

by Stephen P. Bear and Tony W. Rush 



The technology base of electronics and computer compa- 
nies like Hewlett-Packard is changing — software has be- 
come pervasive. In all market sectors the proportion of 
software in individual products continues to increase. Fig. 
I shows the dramatic increase of software in products of 
one family developed between 1979 and 1989. 

Product A produced in 1979 was entirely hardware, and 
contained no software at all. Prodi id B contained 38 
KNCSS (thousands ol lines of noneomment source State 
ments) of Pascal, In 198(> T product C contained 200 
KNCSS of structured assembly language, which is equiva- 
lent bo about ton KNCSS of a high-level language like 
Pascal or C. The current member of the family, product D 
released in 1989, contains some 350 KNCSS of C. 



Product D 



" 200 




Fijf* i- Software rnnrm! of a particular n>» ■-• li< al | ■? ■ ■- :i j I Niiuih. 
fmni 19mta!9S& 



Growth like this is not accidental because there is a feed- 
bark loop I hat dnves the increased functionality provided 
by increased software. Software enables us in design 
products with greater functionality. Initially, this function- 
ality provides a competitive advantage, hut it soon be- 
comes essential to success in live market. To make an 
impact, each new product must have more features and 
more software. 

Software Tkkes Too Long 

This massive change in products, with software providing 
much of the functionality, is happening despite significant 
short comings in the current soft ware development pro- 
cesses. The principal problem is that software develop- 
ment takes too long. The development process is difficult 
to control and defect removal can introduce seemingly 
arbitrary delays. 

Delays increase development costs, but more important, 
they also reduce market share and affect overall lifetime 
profit. Studies of high-growth, short-li recycle markets sug- 
gest that a six-month delay in introducing a product can 
reduce profit by 33%. 1 One HP Division estimates that for 
each new product, finding and removing bugs can cost 
over 1 million dollars,- 

Software development takes too long because it is waste- 
ful Brrors and defects are introduced during develop- 
ment, but are not detected quickly. Further work is Mien 
built upon the erroneous development. When a defect is 
detected, there are many interlocking details, and these 
must be reworked or discarded. During development this 
happens repeatedly Again and again, work carried out at 
one stage is thrown away and must be replaced 

Defects not detected until late in the software develop 
men I process tan affect large amounts of w r ork. Thc\ mc 
difficult, time-consuming, and expensive to correct De- 
fects detected early in the development process require 
less work and typically they are easier and cheat KT ,n 
correct, 

Fig. 2 shows the cost of removing defects detected at 
various points in the software development process, as 
calculated by the software quality engineering group at 
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Fig, 2. Calculated cosl of defect corrf ietection m 

the HI 



one IIP DivisJun. Notice thai costs of removal increase 
exponentially as the development, proceeds. 

It is instructive to look at these figures in a slightly dif- 
ferent way, and to consider the cost of introducing an 
error at various points of the development process, If an 
error is detected by a code inspection or design review 
soon after it is introduced, it can be fixed quickly and 
cheaply. For example, if a specification error is detected 
at specification time, it will be cheap to repair However, 
if it is not detected at this stage, then it is likely to lie 
dormant until the consequences of the error are observed, 
by which time it will be much more expensive lo correct. 

Ij turns out that the introduction and detection of the 
consequences of an error are nested because typically: 

• Errors Introduced during low-level design and coding are 
observed quickly during compilation arid innl lesl 

• Errors introduced during high-level design are observed 
dining integration and system lest 

• Errors introduced during specification arc not observed 
until system test and use. :l 

We can use this relationship to estimate the relative COStS 
of introducing a defect at various points in I he develop- 
ment process. II shows thai a defect introduced early in 
the development process — and not detected immediate- 
ly — will be much more expensive to fix than an error 
introduced during coding (see Fig. 3$. 

Clearly, defect prevent inn during specification and design 
is extremely important Getting ii righl al this point is 
where it really matters. However, if we look at current 
practice, we see that the analytical and descriptive tools 
used during specification and design are very weak. There 
is little attempt lo capture behavior at the specification 
Stage Early narrative docunienis describe features, but 
these are inevitably ambiguous, incomplete, and often 
contradictory. Nigh-level descriptions of behavior are just 
as vague, and precise descriptions often resort. Lo imple- 
mentation details 

The result is a rush to code. Developers do not spend 
time understanding and describing bfhaviur because il is 
hard to capture and COmmimieate, Instead they use Hie 
implementation to document issues and resolve problems, 
Often, i he implementation is the ffesfl precise description 

of what the software will do. 



Many important decisions about overall behavior are 
made by programmers working at the lowest level of de- 
tail. This is not a good way to think about behavior, and 
decisions made in this way are often inconsistent or un- 
desirable, Aspects of behavior emerge from interactions 
that have never t>een explicitly considered or analyzed. 
Behavioral defects embedded in the code are difficult to 
detect by inspection or review. However, they are the 
defects that begin the costly cycle of rework and waste 

Rigorous Software Engineering 

Rigorous software engineering is an approach to software 
development that addresses quality and productivity by 
emphasizing the early stages in the development process. 
Rigorous software engineering concentrates on developing 
an early, precise understanding of the required behavior 
of the system under development. Expensive specification 
mid design errors can be avoided, or detected and cor- 
rected before the implementation begins. 

The rigorous software engineering philosophy could be 
summarized as one of defect prevention. Think carefully 
about what you want to do and get it right the first time, 

The approach is to develop an abstract, but precise de- 
scription of the behavior of the software system. This 
description can be reviewed to ensure that the system 
does what is required. If there are problems, they can be 
fixed quickly and cheaply — long before an implementation 
is created. 

Underlying the rigorous approach are formal specification 
languages, These are mathematically based languages that 
provide support for abstract and precise descriptions of 
software systems. 

Rigor in the Software Lifecyele 

Rigor can be used effectively at all stages of the software 
lifecyele. Naturally, if the early stages of the development 
are more error -prone or more costly if flawed, then those 
slaves are likely to benefit most, 

If we take a Stmpfe model of software development — 
specification then design then implementation then tesl- 
ing — we can show I he application and benefits of 
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rigorous software engineering fm each stage In real soft- 
ware development^ these phases will appear, but thej itui> 
h$ interleaved, repeated, or omitted. 

Specification. Rigorous techniques are particularly useful 
at the specification stage. A rigorous system Of specifica- 
tion is both abstract and precise. Ahstrunion foci 
attention on the essentia] aspects of behavior. An abstran 
description is not cluttered or eonfiased with irrelevant 
details Ir makes the behavior of the system easier to 
understand and to think about. Precision encourages care- 
ful I bought because issues must be resolved and cannot 
he hidden in an ambiguous narrative. 

Together, abstraction and precision make it possible to 
communicate Hie proposed behavior. Reviews and inspec- 
tions can be more effective. Other people can understand 
what is suggested because I hey can analyze consequences 
and identify problems or omissions. 

The specification of die system will construct a model 
thai shows all the required properties of the system. This 
model can be used In resolve difficult issues <>f behavior. 
If the model cannot resolve these issues, then it is flawed 
and needs improvement, hi practice, this makes it diffi- 
cult to ignore tricky areas of the specification. 

A rigorous specification, then, provides benefits to both 
the authors of the specification docuiucuis and the re 
viewers of those documents. Clarity of thought and con- 
cept helps prevent defects from being introduced. Clarity 
of expression empowers reviewers and helps ensure thai 
defects ate quickly identified and removed 

Design, A feature of the rigorous software engineering 
approach is the ability to separate concerns. In the speci- 
fication phase, emphasis is placed on what a system is to 
do. In I he design phase emphasis is placed on how the 
system is to be built because decisions about behavior 
have already been made. It is not necessary lo resolve 
requirements issues while doing design 

Precise specifications provide detailed guidance for de- 
signers. Teams of designers know what is to be done. 
This makes it easier lor the development lo be well-man 
aged because tasks can be defined precisely (design the 
feature whose specification is as follows) and allocated to 
developers, Misunderstandings causing integration prob- 
lems or system errors can be dramatically reduced. 

It is straightforward to combine ihe rigorous approach 
with techniques such as structured design. 4 " This gives 
many benefits, especially the ability lo trace which parts 
of the design implement which parts of the specification. 
This Iraceability is an important attribute of any develop- 
ment process, allowing subsequent eiihaurernents to code 
to be done in a controlled wa> and improving the quality 
ot the finished software product. The article nn page 51 
shows ihe combination of structured design techniques 
and rigoro us speci 11 cat ions. 

(Jood specifications are especially important when soft- 
ware is developed by subcontractors, Rigorous specifica- 
tions cart be made tight enough to allow subcontractors 
to implement precisely the desired functional it y, and for 
l here lo be much less disagreement over the required 
behavior of the system. 



Implementation. As with design, decisions about require- 
ments ha\e already been made, hi addition, at this stage, 
design derisions have also been made. Effort is concen- 
t ruled on producing an efficient implementation of the 
desired behavior. 

The code modules can be traced to the design descrip- 
tions and the design descriptions can be traced lo the 
speeilVuiions. The vocabulary of the specification is used 
in the commentary for the code — for example, to stale 
properties that particular functions depend on lo work 
correctly. 

Testing and Inspections. Throughout the development, the 
deliverables Of the various stages can be tested or in- 
spect ed. Before executable code is available, the specifi- 
cations and design documents can be forma I ly inspected 
using standard industry practices/' The descriptions pro- 
vide precise, independent criteria for correctness In a 
formal inspect ion the reviewers know 7 what the design or 
rode is Supposed to do and can check whether it meets 
lliesc requirements* 

The correctness of test cases can also be reviewed 
against the specifications. The behavior of the system 
should be predictable from the specification and tests can 
lie chosen lo verify this. Industry -si andard testing tech- 
niques"* can be used to supplement the tests from the 
specif! cat ions to catch additional code-orient cd errors. 

Formal Specification Languages 
Rigorous software engineering requires precise but ab- 
stract descriptions of behavior It is possible to write 
these descriptions in a natural language such as English, 
fierruan, or Japanese, but it is very difficult to do so 
without introducing ambiguity and other problems. The 
key lo rigorous software engineering is Ihe use of formal 
specification languages to describe behavior. 

Formal specification languages look like programming 
languages in that they both have special syntax and use 
special symbols, bill they do very different jobs. A formal 
specification language is designed to describe what a 
product is lo do while a programming language is de- 
signed to describe how it is to be done. 

The syntax and symbols of formal specification languages 
an- based on discrete inathoma!ies. This can be intimidal- 
ing to begin with, but in tact the math is quite simple — 
far easier ihan the continuous mathematics routinely used 
by hardware engineers. The math is used to provide an 
abstract mathematical model of the system. This is not a 
new idea since it is the standard approach in engineering 
to use a model to understand the behavior and properties 
of a system. 

One such language is the Hewlett-Packard Specification 
Language, IIP-SL 1 '. IIP-SL has been developed at HP Labo- 
ratories in Bristol, England, and has already been used on 
real software development projects at several divisions in 
HP The language is supported by a toolset (the IIP Speci- 
fication Toolset), based on the emacs editor with an op- 
iioual interface to Ihe IIP Soil bench 1 u product. The tool- 
set allows the production of specification documents 
containing a mixture of natural language and IIP-SL I 
ing the toolset, specifications can be checked for syntne- 
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tic correctness and for type eonneeiness- The tooted is 
not a Hewlett-Packard product, bul has been made avail- 
able to academic and research institutions. 

ILP-SL is a specification language lhal uses data types, 
functions and logic to describe properties of software 
systems. These properties can be expressed at both a 
high level of abstraction and et of precision 

S combination oral n and precision allows mi 

portant behavior u* be captured withmn becoming tas 
a mass of detail. 

An Overview of HP-SL 

The HP Specification Language, or HP-SL. is a notation 
for describing the behavior <>r software Systems and com- 
ponents in an abstract yet precise manner. The lanjni \ 
allows attention to be focused on what a system does. 
while deferring decisions on how a system is imple- 
mented. 

The following sections introduce SOin€ Of the main parts 
of HP-SL. This should provide a useful guide to interpret- 
ing the IIP-SL specifications presented in this issue. 

Values 

In HP SL values can he given names. These names can 
then be used to represent values. The following declara- 
tion gives the name nam to the value i 

val num: Int = 3 

The declaration also says that num is of type lm (integer). 
Int is one of the predefined HP-SL types. A declaration 
need not define exactly which value is chosen fof a 
name. For example, 

val mirr\] lm 

says lhal num | is the name for some value of type Int, bul 
does nol say which particular value is chosen. Laler - 
lions will show that logic can be used to constrain values 
lhal art* given names. 

Value declarations ran appear al (he top level of a speoi- 
llraliun fas above) in which ease their scope is ihr entire 
Specification They can also be lised to define local values 
using a let expression. The let construe! is similar to I hat 
found in many functional programming languages. For 
example, the value of I he expression: 

let 
val one, Natl ^ ] 

val ten: Matt ^ 10 
in 

one t ten 
endlet 

is the natural number 11. The names one and ten are de- 
fined in an inner scope and are nol visible outside the let 
expression. 

r iypes 

'types iu IIP SL are much like lypes in a programming 

language in that they are collections of similarly struc- 
tured values that permit the same scl of operations. Tims 



numbers and Booieans (truth values TBUE and FALSE) are 
distinct types, since arithmetic operators *, etc.) 

work on numbers but not on truth values, and the I . 
operators (a, v. =>. etc.) work on truth values hut not 
on numbers 

HP-SL provides a number of predefined types and w; 
of const meting brand new- types from existing types. HP- 
SL also allows names to be given to types 

Predefined Types. Table 1 lists the pr types m HP- 

SL These types are available for use in all specifications. 





Table I 






HP SL Predefined 


Types 


Name 


Description 


Values 


Bool 


Boolean, truth vui 


TRUE, FALSE 


Real 


Real numbers 


0,1142,0.00023 


Int 


Integers 


5,0,99 


NatO 


Natural numbers from 


M 


Natl 


Natural numbers from 1 


9,1 


Char 


Characters 


'a\ '\[newline]' 


String 


Sequences of characters 


"abc" 



The numerical lypes (Real. Int. NatO, and Nail) have all the 
expected aritlntielical operators defined on Them i -, - T 
=1= , /, <-, >. mod. etc . i. The Boolean type has the five stan- 
dard Boolean operators defined on il ( A logical AND, v 
logical QR\ => logical implication, ^ logical negation, and 
<-> logical equivalence). 

Naming Types, In IIP-SL, lypes ran he given additional 
names. The following declaration gives the name MyNLim 
in the exisling lype NatO. 

syntype MyNum ^ NatO 

This declaration docs nol introduce a new type, but mere- 
ly gives another name to an existing type. Values of type 
MyNum are indistinguishable limn values of type MatQ. (The 
keyword syntype derives from synonym type). 

Constructing Types. IIP-SL has soma predefined type 
constructors thai provide ways of creating more compli- 
cated types in>m other types. The must common of these 
are sets, sequences, and maps* 

Sets. These types are used to model colle* -rums of data 

for which "Ml''! and ivpHinon ;uv ummporfanl. Sel types 

in IIP SL art constructed using ihe type constructor Set. 
For example, 

syntype Natset ^ Set NatO 

associates the name Natset vvilh sets of natural numbers 
Values of Ihe set lypes are written as follows: 

val e(Tiply_sel: Natset £ ( } 
val even set Natset ^ ( 2, 4, 6 } 

Where empty_set is a name for the empty set, and even_set 
is a name for i Iu- sei containing three elements % 1, 

and i'r 
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For large sets, it is not practical to list all the values. 
Therefore, HP-SL provides a syntax similar to the conven- 
tional mathematical set comprehension. 

val one_to_a_thotisand ^ { x I x: NatO * > 1 A x < IDQO } 

The set one_to_a .thousand contains all the natural numbers 
between I and 1000. 

HP-SL provides all Lhe conventional set operators (U set 
union, n set intersect ion, E set membership, \ set differ- 
ence, and C subset), 

3 E {J 5} = TRUE 

i1 H 2} U {2 r 3 r 4} = $$$& 
{1,2} n {2,3,4} = {2} 
{1-2} \ {2,3,4} « {1} 
{1,2} C {1,2,3} = TRUE 

Sequences. These types are used to model collections of 
data for which order and repetition are important, Se- 
quenee types in III'SL ate constructed using the type 
constructor Seq< For example, 

syntype Natseq ^ Seq NatO 

associates the name Natseq with sequences of natural 
numbers. Values of this sequence type are written as fol- 
lows: 

val empty_seq: Natseq ^ < > 
val even_seq: Natseq ^ C 2, 4 » 

where empty _seq. is defined to be Lhe empty sequence, and 
even_seq is defined to be the sequence of two elements, 
the First of which is 2 and the second of which is 4, 

There are a few standard names for sequence operators. 
The names for the HP-SL sequence operators are listed in 
Table II. 



val empty: Char_to_num 4 [ ] 
val amap: Char_to_num 4 [ 'a' 
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Table 11 
Operators for Sequences 


Operator 


Meaning 


Example 


hd 


Head of a se- 
quence 


hd < 2, 99 > = 2 


ti 


Tail of a sequence 


tl < 2 T m %■■* MM> 


© 


Sequence con- 
catenation 


«2 ? 99, 2 T 99» 


elem 


Sequence lookup 


(elem <2, 99> 2} = 99 


Jen 


Length of a 
sequence 


len <2, 99> = 2 



Maps. These types are used to associate values of some 
type with values of another type. In programming lan- 
guages, maps are implemented by structures such as hash 
tables, association lists, and trees. In HP-SL map types 
are constructed directly using the type constructor % m 
For example, the definition: 



syntype Char_ta_num ^ Char 



NatO 



gives the name Char_to_num to the lype mapping values of 
type Char to values of type NatO. Values of this map type 
are written as follows: 



where empty is the empty map and amap is the map that 
associates a' with 2, 'm r with 1, and p' with 1. 

The function lookup is provided to return the associated 
value in a map. For example, 

lookup amap r a' - 2. 

Another function, dam, is provided to calculate the ( If 
menls in a maps domain. For example, dam amap = (V, J m', 

Pi 

Introducing New Types, We have already seen ways of giv- 
ing names to types usin£ lhe syntype keyword. Doing this 
does not introduce a new type, it merely gives a name to 
an existing type. To introduce a new type, HP-SL provides 
the keyword type. This can be used in a variety of ways 
to construct new types, most of which are advanced top- 
ics in HP-SL. The most common use of type is to make 
record and union types. Iterord types contain values of 
several other types, and union types permit, choices be- 
tween alternatives. 

For example, consider a record type used to represent 
boats. To represent a boat in this simple example, we 
only need to know the displacement of the boat and the 
number of engines it has, The type Boat will be adequate 
for this (assume we already have a type Weight to record 
die displacement). 

type Boat 4 
B boat > 

(engines: Mat1 H 
displacement: Weight) 
I 

This definition states that values of type Boat have two 
fields: engines and displacement. The type of the engines field 
is Natl, w r hile the type of the displacement field is Weight We 
can construct values of Boat using the name before the > 
symbol — boat. 

val single: Boat A bo a HI 5000) 
val double: Boat £ boat(2, 7000) 

The value single is intended to represent a single-engine 
boat with displacement 5000, and double a twin-engine boat 
with displacement 7000, Just as in a programming lan- 
guage, the fields of a record value can be accessed. In 
HP-SL, the fields are accessed by functions generated 
from the field names used in the type definition. 



engines(double) = 2 

displacement(single) 



5000 



Consider now a type Ship T values of which are either 
boats (as before) or yachts. Yachts have sails, not en- 
gines, and an important statistic is the sail area. We de- 
fine this using the following union type: 

lype Ship ^ 

I boat t> 
(engines; Nat1 H 
displacement: Weight) 



] 



I 
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[yac 

{sail_area: Area, 
displacement Weight) 

: 

The symbol "f is used to indicate alternatives in union 
types. 

We can redefine the previous boats as ships: 

val single: Ship & boattl 5000} 
val double: Ship t boatO, 70001 
val yachn.: Ship t yacht(400, 20001 

The field accessing mechanism works as before: 

displacement double) = 7000 
displacenient(vacht}| - 2000 

Functions 

Fund ions are used to model computations and calcula- 
tions, Functions in HP-SL are "pure" in the sense thai 
they cannot have side effects. 

Functions are defined in one of two ways — explicitly or 
implicitly. An explicit function definition gives a formula 
io calculate a resuli from the knpti&s An implicit function 
defiiiition gives a test or definition of which result is cor- 
rect for the given inputs. To make this clearer, consider a 
function max that returns the maximum of two integers. 

Defined explicitly, a function looks like: 

1: fn max : Int x Int — Int 
2: is maxta v) 

fc$ 

4; if x < y 
5: then y 
6; else x 
7: enrjif 

Line 1 gives the signature 1 of the function. In this exam- 
ple the signature says that max takes two values of type 
Int and returns one value of type Int. Line 2 gives names 
for the formal parameters of max, x and y. Line 3 
introduces the body of (he function definition, and says 
that what follows will be an algorithm to calculate the 
result given the inputs. lines 4 to 7 are the explicit algo- 
rithm. 

Defined implicitly, a function looks like: 



1: 


fn max Int X 


Int -► Int 




2: 


is max(x, y) 






3: return larger 






4: 


post 






s 


(larger = x \ 


larger - 


V) 


6 


A 






7. 


larger >x 






8- 


A 






9 


larger > y 







Lines 1 ami 2 of this < h 'fin i lion are identical to the explic 
ii definition. Line 3 introduces the name larger for the re- 
sult Line I Introduces the body of the implicit definition 
(known as a postcondition, hence the keyword pasn. 

*A signature defines The argument types and ths result type of a function 



Lines 5 to 9 are a test which is true precisely when the 
value larger is the correct result for the function. 

The implicit style can allow quite complicated functions 
to be defined in a simple way t without having to give an 
algorithm. For example, a square root function could be 
specified implicitly as follows: 

fn sqrt: Real =♦ Real 
is sqrflr) 
return s 
post 

r = s • s 

The square root example as given is, of course, incorrect. 
The square root of a negative real number is not itself a 
real number. A specifier has two choices here — extend 
the definition to complex numbers or restrict the defini- 
tion to nonnegative reals, A particular strength of MP-SL 
is its ability to restrict the scope of function definitions in 
a natural way. This is done by adding a precondition to 
the function definition. This precondition is a Boolean 
test that determines % ? alid inputs to the function. In the 
square root example, the definition given is only valid for 
inputs greater than or equal to zero. Hence the corrected 
definition is; 

fn sort: Real — Real 
is sqrtfr} 
pre r > 
return s 
post 

r = s * $ 

Relations 

For modeling operations on the system stale, it is useful 
to identify the particular kinds of functions that return a 
Boolean result. Such functions are called relations and 
have a special syntax in HP-SL, For example: 

rein vowel ; Char 

is voweKcl 

= 

c E f a\ V r V; V, V} 

defines a relation called vowel which is true just for those 
characters that are vowels. So the expression vowelt'a'l is 
TRUE, whereas the expression voweirkl is FALSE. The mail 
system described in the article on page 32 shows how 
relations arte used to model system operations. 

Using Logic 

The use 0f logic is pervasive in HPSL Logic can be used 
to constrain values, types, and functions to specify in- 
tended properties precisely without needing to give algo- 
rithms. The implicit form of the function definition is one 
way in which logic call be used. 

Logic can be used to constrain value definitions by using 
the sat keyword. The sat is shorthand for satisfies. 

val x Int sat x > 10 

val y: Int sat y E (1,9,31} 
This defines * to be some integer greater i ban 10, and y 
to be one of I lie values 1, 9 t or 31. 
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Logic can also be used in constrain types. Consider a sei 

of characters. Tb model pan of a system, ii may be tme 
that these seis can never be empty, IIP-SL gives a simple 
way of slating such constraints using the inv keyword (inv 
is short lor data type invariant)- 

symype N_e._char_set ^ Set Char inv s - s =£ { } 

The s between (he inv and lite ■ is a name lhal represents 
<\ iypi< at member of i he type N_e_char set. This name is 
used in die logical expression alter the - 10 slate that all 
such members would he nonempty. So I he set { a , '6'} 
WOUid he of type N_e_ char, set htil Ihe set {} would nob 
The notion of invariant allows powerful statements about 
expected properties of systems. This aids the production 

and analysis ol specifications. 

In addition ?o ihe situple logic expressions used so far 
(propositions! logic k IIP-SL also provides predicate logic. 
Predicate logic extends prepositional logic by introducing 
quantifiers thai allow statements about all values of some 
lype or about some values. The symbol V, read as u for 
all" or Tor any." is used lo make statements about all 
members of some type. The expression 

( V x: NatO - x > 0) 

says that: for all x of type NatO, x :> I). Another quantifier 
is thi* symbol 3, read as "there exists,* whirh allows 
statements about some values. For example. Ihe expres- 
sion 

( 3 x: Char x - V) 

says thai: dune exists an x of type Char such that x = 'a' I 

Who Has Used Rigorous Techniques? 
Rigorous methods are creating increasing interest in the 
software development community. The articles 011 pages 
46 and 51 describe experiences using IIP-SL on real proj- 
ects at two IIP divisions. HP laboratories Bristol is afaq 
providing consulting sen ices to PIP divisions in Colorado, 
California, and Scotland, 

< >mantzations outside of IIP have used formal sperifira- 
linjis in various ways. For instance, one organization used 
formal specifications to develop a reusable framework for 
a family of software products for mstrumenis. 11 They 
concluded thai the application of formally based lech- 
niques in this fashion proved to he cos I -effective, and Ihe 
reusability oft.be specifications has translated into reus- 
able components. Another unitization used formal lech 
mimes as part of their rcengmcering efforts on a mayor 
software product. 1 - They used the formal notation Z, 
which is very similar lo IIP-SL. 10 manage the introduc 



lion of new features hum rim product. The specification 
document became a record oj flu commitmeni promised 

by The designer lo the customer. Many soil ware houses in 
Europe have successfully used formal and rigorous tech- 
niques for a wide range of applications ranging from safe- 
ly ethical applications like air-traffic control to telecom- 
munications cont rollers. 

Introducing Rigorous Techniques into a Project 

For many people, rigorous (echniques represent a radical- 
ly different way of approaching software development. 
Adopting this approach can be far from Straight fur ward. 
In recognition <>f (his problem, Ihe software engineering 
depart mcul ai IIP Labs in Bristol has a project team 
railed the applied methods group, or AMG, whose mis- 
sion is to act in collaboration with olher pails of IIP to 
introduce formally based methods, 

To dale, a phased approach has been taken which starts 
with a small, low-risk project and develops to a more 
substantial collaborative project. It is important that the 
projects have the following features: 
Enthusiasm from the project engineers to try something 
new 

Full effective commitment frotn all Ihe managers in- 
volved, from project manager to lab manager 
Commitment to project -ecu I ered training just before the 
collaborative project 
, Realistic expectations of whai benefits and costs are in- 
volved. 

In addition, the product being developed needs lo have a 
high chance of suecossful delivery to market. The collabo- 
rations aim to be at the center of I lie product develop- 
ment, 1101 merely providing an ancillary technology. 

As with introducing any new technology, there are iv 
quiremenls 011 the rigorous techniques. These require- 
ments include iraining, effective technical suppori. ade- 
quate documentation, and high-qualily supporting tools 
thai can be integrated into the normal develoj intent envi- 
ronment of the project. A large part pi the team's wwk 
has hem ft) ensure that this level of suppori is available 

Conclusion 

Rigorous software engineering is an approach that is both 
practical and theoretically sound. Its introduction into the 
software engineering community is progressing. It offers 
scope for substantial irnprovemeuls in software Quality 
and productivity In addition, the approach is likely to be 
developed further lo suppori a wider range of applica- 
tions. 
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Specifying an Electronic Mail System 
with HP-SL 



Starting with a list of system features and capabilities, an HP-SL 
specification for a simple mail system is developed and the steps involved 
in this process are analyzed. 

by Patrick G. Goldsack and Tony W. Rush 



Specifications tend to be used for three main purposes. 
The first is to help analyze the requirements of a system 
by constructing an abstract model. The process of 
constructing the model, and the subsequent reasoning 
about its behavior, wall typically result, in extensive dis- 
i nssion about the fundamental required behavior of the 
system. The second purpose is to provide concrete, unam- 
biguous descriptions of the system that are open to de- 
tailed review. The third purpose is to act as a guide to 
the developers of the system by describing the necessary 
properties of their programs. 

This paper provides an introduction to using HP-SL nota- 
tion for the specification of a simple mail system. Al- 
though the mail system and its specification are simpli- 
fied t enough of the system is specified to demonstrate the 
essential aspects of the HP-SL notal ion and the specifica- 
fion process. Most of the HP-SL notation used in this pa- 
per is described in the article on page 24. 

The System 

The mail system defined in this paper is similar to the 
electronic mail systems in common use such as HP Desk- 
Manager and the various mail systems available on sys- 
tems like the HP-UX operating system. Our example mail 
system has the following features and capabilities, 

i The system has a collection of users who are registered 
witli the system. 

> Each user has three trays: an in_tray. an outjray, and a pend- 
ing_traY' 

• Users compose messages by entering them into their 
pending_tray 

> Users may read and delete messages from their in „tray, 

> I r sers post messages by moving them from their pend- 
ingjray to their out_tray. 

i The system transmits messages from a given oLrtjray to 
the recipients* in_tray. 

A real mail system would provide many more features. 
However, this choice of features is sufficient to illustrate 
the use of HP-SL and demonstrate some of the advan- 
tages of formal specification. 

Building the Specification 

FYom the natural language description above, we can 
identity the following entities (data types) that must be 
modeled: 



■ Users 

■ Messages 

• Trays (injray, ouLtray, and pending Jray ). 

There are also constraints between the entities— for ex- 
ample, each user has three trays. We ean also identify 
items of vocabulary thai must be defined such as the 
meaning of each of the three tray types and the notion of 
being registered. Finally; several operations are identified: 
t Reading a message 

• Deleting a message 

• Entering a message 

• Posting a message 

• Transmit ting messages. 

Message Data Types 

Entities within a specification are represented as values 
of a type — a concept present in many high-level program- 
ming languages. However, HP-SL has a variety of types 
that are particularly suited to modeling requirements and 
behavior 

Person. The fust type we define is that of person, which 
will be used to represent potential users. 

type Person 

This is an example of an abstract type. In this example, 
by making Person an abstract type and providing no func- 
tions that operate on values of the type, we are stating 
that the particular properties and attributes of the typ6 
are irrelevant to the specification. In fact, the only prop- 
erty we can asseit about values of type Person is equality 
(or inequality j. 

Contents. The next type is that of the message contents. 
This is also defined as an abstract type. Later this could 
be refined, for example, into a sequence of bytes. Be- 
cause its structure is unimportant to the specification, the 
type Contents is left abstract. 

type Contents 

Message. Tu define a message, we noie that there are 
three interesting properties of messages in the system; 

■ The identity of rhe sender of the message 

■ The identity of the message's intended recipients 

• The contents of the message. 
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In addition, we need to be able to construct messages. 
We could define Message as an abstract type as before, 
and define functions to construct messages and to extract 
inforniation. 

type Message 

fn message Person * Set Person x Corrtertts -» Message 
fn sender Message — » Person 
fn recipients: Message — Set Person 
intents: Messege -* Contents 

The function message will construct messages and the 
other three functions will extract the appropriate informa- 
tion from values of type Message. 

We could also use the following shorthand lo define what 
these functions do. 

type Message £ 
[[ message 

(sender: Person. 

recipients: Set Person, 

contents: Contents! 
II 

This type is essentially equivalent to a programming lan- 
guage record type. Messages are constructed using the 
function message and the functions sender, recipients, 
and contents are equivalent to field selectors in a pro 
gramming language* 

Validating the Message Definition 

The definition of the type Message makes certain decisions 
regarding the behavior uf the mail system which should 
be validated against the intended properties of the sys- 
tem. In any completed specification document, all formal 
descriptions should be accompanied by a discussion C& 
the real-life Interpretation of the mathematical model. If 
one looks ai the information captured in each message, 
the following Questions and considerations arise. 

Sender. A single person or multiple authors? We decide 
here That the sender field is used to represent the name 
ni ihr prison who actually enters and posts the message; 
This can be compared to the differing approaches of HP 
Desk and HP-UX mail 

Recipients. The recipients are expressed as a set of type 
Person. Because a set has no order and no duplicates, the 
consequences of this rlioice must he explained The lack 

of ordering implies ihat no precedence can be given to 
individuals within ttte set bs virtue ol their mernhership 
of the set. This seems a reasonable decision for this spec- 
ification. 

The lack of duplicates can be interpreted in one of two 
ways. First, it can mean that a message may not be 
created when a person OCCUTS multiple times in the recipi- 
ents field of a message, Thfa seems unreasonable tf aliases 
for si Ms of people are introduced and such aliases are 
allowed to overlap. Second, it can mean that duplication 
of a prison in the recipients field has no effect on the 
heliavior uf the mail system. It is just as though (hat tier- 
son were mentioned jiisl <>n< r. which in tins c&$& is ihe 

intended ml.erpretalimi. If one really wanted the first in- 

fcerpretation there are alternative ways nt modeling the 

type ilia i would be more natural 



Contents. This is a type for which we have no further de~ 
tails about its internal makeup because it has no efh 
on the mail system behavior. This is perhaps one of the 
most significant differences between this example specifi- 
n and a real mail system. In practice, an arbitrary set 
of conventions is used to l; . ricance to ceriain 
forms of message contents such as a line starting with 
the chanv r with the string ' 

This choice of properties is the minimum necessary for 
this specification example In a real system, messages 
would have many more properties defined, such as date 
sent and priority. In this specification, these would be 
added as additional fields of the type Message. 

Defining the types used in a system builds up a vocabu- 
lary that can be used to describe the system's properties. 
This vocabulary can be extended to describe all aspects 
of the system in a completely formal and unambiguous 
way. This is done by defining functions that manipulate 
the data at a higher level Once this extended vocabulary 
is in place, statements of system behavior become 
straightforward. This leads to one of the main benefits of 
formal specification— the right language with the right 
abstractions make discussing design issues much easier 

For messages, a useful concept is the set of people refer- 
i need within the header of a message — the sender and 
the set of recipients The function addressed obtains this 
information from a message. 

fn addressed: Message — ► Set Person is 
addressed(ml 4 {sendertmft U recipients(mj 

The value sendedm) is a set containing only the person 
who sent the message. This is added into the set of recip- 
ients (using set union u ) to produce the set of all per- 
sons mentioned in the caessa 

Tray Definition 

The initial description of the system mentions three sorts 
uf trays thai belong lo each user. The specification 
groups these three together as a type Trays. 

type Trays ^ 
I trays > 

(injray: Tray, 

out Jray: Trsy, 

pending tray: Trayl 
I 

Km h of the three trays is of type Tray, which is defined to 
he a set of messages. 

syntype Tray ^ Set Message 

Note that this type declaration is slightly different from 
tlie previous ones. For a start il is introduced by the key- 
word syntype which stands for synonym type. A syntype 
introduces a name for a type, not a new type (unlike <\ 
type declaration). Thus Ihe t$p& expression Set Message 
ma> he used interchangeably with I lie type expression 
Tray, 

Validating the Tray Definition 

The decision to model 1.1 ie lra> as a set of messages dr 
serves closer inspection. A* previously discussed, using 
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sets has two consequences- Kiim. there is no order in the 

ssages reflects wiihin the tray's structure, and second 

duplicate messages are ncii possible wiihin a trav. I5ie 

question In 1 >e answered is whoiher either of these Iwo 

restrictions will cause difficulties in modeling the hchav- 

Ordering ihe messages in a nay might reflect one of two 
kinds of attributes: message attributes and dynamic aflsrf- 
butes. 

Message Attributes. These arc attributes that are only de- 
pendenl ob already existing fields of the mail messages. 

Examples u! message attribute orderings include: 
The alphabetical order of the sender^ 
A priority order with 1 1 u ■ priority of a message being cap- 
tured wiihin ihe as yet undefined contents field of the 
message. 

This kind ni ordering can be recreated whenever ii is 
required, so not rapturing this information in the Tray type 
is relatively unimportant, However, in practice il would be 
useful to use an ordered data type if the attribute order- 
ing were central to l he operation of the system. 

Dynamic Attributes. Tin -m are attributes thai are the result 
of some aelion or ordering Of actions. An example of Ihis 
rniighl he the order in which messages are placed in a 
tray. Ji is always possible to capture this order by having 
information that represents a messages position in the 
sequence added as an attribute of the type Message, It 
would be better, how- ever, to take a much more direct 
approach and use, say, a sequence instead of a set, 

Thus a particular choice of modeling is achieved by con- 
sidehng both ihe mathematical properties of the model 
and the directness with which it captures ihe intended 
interpretation of the real system. In this instance, mail 
messages in a tray are identified directly rather than by 
position in an ordered sequence, so an unordered collee- 
tion seems lo be a reasonable decision. 

The restriction on duplicate messages is somewhat less 
clear. Consider the injray. The intention is to ensure thm 
recipients only gel a single copy of a message. However, 
this is already indicated for Ihe recipients 1 being a set of 
people, and therefore, messages are only ever transmitted 
once to an individual, The only other way in which a 
message can be senl iwiee is for the sender to do so 
explicitly as iwo separate send operations. The quest ion 
is whether we wish repealed u ausuiissions To eollapse 
identical messages at the receiving end. It is not clear 
thai this is an intended asped of the behavior of the mail 
system. The type used for the mjray field could be weak- 
ened to an unordered collection with duplicates (com- 
monly called a multiset or bag). 

Note that there is a temptation at this point to say that 
tlii* undefined contents field might contain a unique refer- 
ence tor every message placed in the in_tray, so that dupli- 
eates caused by repeated transmission in fact result in 
different messages. However, if Ihis were the rase, il 
would be an essential property of the system's behavior 
at ihe Current level of abstraetion and SO should be mod- 
eled direet |y. Similar arguments tor allowing duplicates 
may be made for the two other trays. For the purposes of 



this example specification, the type Tray will remain as a 
set to avoid introducing huge amounts of I IP-SI, le\L 

Although this example may be elementary, il is typical 
when using formal specification languages that many 
questions arise both from ihe process of constructing die 
Specification and from formal reviews of the specification 
A si yle is rapidb acquired that questions every modeling 
decision in great delail and considers die consequences. 
This is only possible, if the underlying modeling technique 
has a formal basis allowing sound reasoning. 

With many data types it is convenient to define additional 
properties that make other pails of the specification sim- 
pj< ■[ ■— in (his ease, ihe mail in a tray for a particular user. 
The function mailjor Formally tie fines this property. 

fn mail for: Person ,■• Tray -» Set Message is 

maiffof (u, trayf 
return msgs 
post 

Iv m:Message - 

m E msgs ** m E tray A u E recipients{m) 
i 

This function returns the set of messages (msgs) in which 
each message m both is in the tray (m e trayl and has the 
addressed person u as one of Ihe recipients (u E recipi- 

eruslm}). 

System Definition 

The mail system consists Of a collection of people, eaeh 
with three trays. This association is specified by using a 
map from values ol type Person lo values of type Trays. 
The following definition states that each user can only be 
associated with a single collection of Trays. 

syntype IVfail_system £ Person 1> Trays 

Now that the system has been defined, the concept of a 
user being registered on the system can be specified. We 
say that a person is registered it that person is in the 
domain of the system mapping, Ilenee that person is 
associated with a collection of trays in the system. 



In registered; Person * MaiLsystem 
registered (u, s) 



Bool is 



The registered function ret urns a TRUE value it the person u 
is registered in system s. The type Mail system will be re- 
fined laler in this specification. 

Operations on the System 

The types ol data used in the sysiem have now been de- 
fined along with functions defining additional properties 
of the data. The operations listed in five informal require- 
ments description ran now be defined, 

• I sers compose messages by entering them into their 
pending .tray 

• I sers may read or delete messages from their in tray 

• Tsers post messages h\ moving I hern from their pend- 
ing_tray to their outjray 

• The system transmits messages from a given out_tray to 
the recipient s injray, 
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Entering a Message. The* relation input defines ration 

of entering a message into a users pendmg_tray (in prepa- 
ration fur sending). This will be defined as p relation 

it the state of the mail system before the messai: 
entered, the message to be entered, and the state of die 
mail system after the message has been enfc HP- 

us relation Looks like: 



Message 
input (sys, message, sys'i 
A 



MaiLsvsterrr is 



This relation is true if the parameters are in the relation- 
ship and false otherwise. The input parameters sys and 
sys r are used to indicate the before and after stale of the 
mail system (s» Specification of State in HP-SI/ on 
38). 

when defining operations, it is useful to consider what 
constraints can be placed on the operation's parameters. 
It might be considered a valid restriction on ihe use of 
ihe input operation that the message placed in the pend- 
ingjray can only be addressed to registered mail-system 
users. If sm. fins restriction may be captured using a pn- 
eondition, which is a predicate thai musi be satisfied by 
the input parameters before the op m be use I 

rein input : MaiLsystem :•■■; Message x MaiLsystem is 

input (sys r message, sys') 
pre 
(V user *E addressed (message) registered(user r sysH 

This restriction imposed by flus precondition is artificial 
since it does not prevent a message from being addressed 
to a user who might be deregistered from the system 
alter ihe message is placed in Ihe pending Jray but before 

transmission, A less restrictive form <>rihe precondition 
would be to inquire ihai ihe sender n\ the message be 
registered wiih the svsiem. The following definition says 

(hat the sender's pendingjray has the new message added 
((Ml and thai this is the only change. 

1: rein mput MaiLsystem x Message X MaiLsystem is 



input (sys, message, sys*) 

pre registered (senrJer(message), sys) 
A 



let 



2 

3 
4: 
E 

f 
7: 

8: 
9, in 
10: dom sys' = dom sys 



\f$\ i r : i - . fi & -i-Im [message] 
val trays ^ lookup sys from 

val trays' ^ lookup sys r from 



11: 
12: 

13: 
14: 
15: 
16: 
17; 
18: 



A 
(Vp 



f dom sys \ {from}) ■ 

(lookup sys' pi = (lookup sys pH 



injray(trays') = m_tray (trays} 

A 
out_tray(irays J ) = out tray (trays) 

A 
pending_tray(trays) = pendingjrayltraysl 



{message} 



19: endJet 



Lines li to S provide local names for: 

* The sender ot ihe message (from) 

* The senders I rays before ihe Operation (trays) 



• The senders trays after ihe operation (trays '). 

The first two clauses {lines ID and 12 1 ensure that the 

stem does not change in an unwanted way. The ! 
clause ensures that no people are added or removed from 
the system (the domains of the before and after sta 
are identical), and the second dans all 

hm the sender, the system map does n«.i < hange. 

The final three i nes 14. i 

the use for each 

Of the three trays. 

i9es that state that die system does not change (lines 
10-12) can be captured ill the following relation between 
son- 

rein change_only; MaiLsystem x Person x MaiLsystem is 

change_only fsys f user, sys" I 
A 

dom sys' ~ dom sys 

A 

( V p E (dom sys' \ {user}) ■ {lookup sys' p I - (lookup sy^ p}] 

Given this definition, input can he rewritten more succinct- 
l\ as: 

rein input: MaiLsystem x Message - MaiLsystem is 

input (sys, message, sysl 
pre 

registered tsenderlmessageL sys) 
i 
let 
val from £ sender (message] 
vat trays 4 lookup sys from 
vaf trays' ^ lookup sys' from 
in 
change_onfy (sys r from, sys') 

A 

in_tr ay [trays') = in, trayl trays) 

ouLtraydrays'l = out_tray(trays) 

pending_Kay(trays) = pendingjray(trays) u {message} 

endlnt 

Deleting a Message. The operation delete removes a meS 
sage from a user's m_tray. The operation lakes a user (of 
\y\u- pprsui'. who j^ deleting the message and a message 
to he deleted as parameters, The new state < lifters from 
the old only in that ihe message has been removed from 
the user s injray. The fonn of ihe definition is stw% similar 
to the relation input 

rein delete: MaiLsystem x Person x Message x MaiLsystem 
is 

deletetsys, user, message, sys') 
pre 

registered (user,sys) 

A 

message E in .tray (lookup sys user) 
A 

charige_only (sys, user, sys') 

A 

injttay (lookup sys' user) = in. tray (lookup sys userf\ 
(message) 

A 

outjray (lookup sys' user! uut_tray (lookup sys user) 
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A 

pendingjray (lookup sys' user) 

user) 



pendingjray (lookup sys 



This relation has a precondition that states two things: 
Thr user Ls registered (in the domain of the system map) 

I lie given message is initially iji (lit* users in tray. 

Given that the precondition is satisfied, the remainder of 
the relation specifies that only trays associated with the 
user should be changed and thai the message should be 
deleted front (he users injray, hul the users outjray and 
pendingjray remain unchanged 

The second pan of the precondition i night he considered 
overly restrictive. The behavior specified in die precondi- 
tion is actually valid whether the message was there at 
the start or not (removing a nonexistent element from a 
si t leaves the set unchanged). However, this would imply 
that the correct behavior is silently to do nothing when 
the user asks to delete a nonexistent message. In ibis 
specification we wish to leave open the possibility of 
some other error behavior so we do not fully define the 
operation. 

Posting a Message. When a user wishes to move a mes- 
sage in the pendingjray to the outjray for delivery, the 
pastjnessage operation is used, 

rein postjnessage: Mail_system x Message ti Mail_system is 

postjnessage (sys, message, sys') 
pre 

registered (ser>der(message),sys) 

A 

message E pendingjray (lookup sys (sender message!) 
A 

let 

val from ^ sender (message) 
in 

chang e_only (sys r from, sys'] 

A 

injray( lookup sys' from) = injrayOookup sys from) 

A 

outjraydookup sys' from) = outjrayjlookup sys from) 

U {message} 

A 

pendingjray (lookup sys' from) - 
pending jraydoakup sys from) S {message} 
endlet 

The specification states that the message is deleted from 
the users pendingjray and added to the user's outjray, No 
Other pans of the system are changed. 

Transmitting a Message, The next specification defines the 
action of the system in transmitting all messages in a 
particular outjray to their intended recipients 1 injrays, 

1. rein transmit Mail_system x Person x Mail_system is 



transmit (sys, user, sys') 



pre 



registered (user r sys) 

dom (sys") =■ dom (sys) 

A 

outjrayHookup sys' user) 

A 



{ 1 



10; (VpE dom(sys) 

M pendingjrayllookup sys p) = pending j;ay(lookup sys p) 

12: A 

13: injray (lookup sys" pi = 

14: in Jraydookup sys p) _ ! 

15; mailJor(p, outJray{ lookup sys user)) 

16; A 

17: p * user =*> (outjray (lookup sys' a] 

IB; = outjray {lookup sys p\) 

19: ) 

This specification has a slightly different format from the 
Others. All users are treated identically wilh respect to 

iheir m .trays fin lines 14 and 15 the messages fur Lhe user 
are added to the injray) and their pending Jrays (in line 11 
the pending Jrays do not change). 

The behavior with respect to the outjrays differs between 
the sender and the other users. The senders outjray is 
lefl empty (line 8). The other outjrays are unchanged (line 
IT), tare being taken to ensure that this clause does not 
apply to the sender by guarding il with the condition p * 
user. 

The clause on line 6 ensures that no one is added or re- 
moved from the system by this operation 

Because eveiy user's trays are potentially altered, the 

chang e^only relation cannot be used. 

Reading a Message. The final operation is that of reading 
messages. This operation is modeled by the function mes- 
saoes_Qf. which returns the set of messages contained in a 
user's injray. 

fn messages_of: Mail_system x Person -* Set_Message is 

messages j)f (sys, user) 
pre 

registeredjuser.sys) 

in Jraydookup sys user} 

Reasoning About the System 

The primary advantage of" formal specifications over infor- 
mal specification techniques is the ability to reason about 
the properties of the specification. This is done lor two 
reasons: 

* Since statements about behavior can be written in a for- 
mal language for which there is a sound set of inference 
rules, it can be determined if these statements are consis- 
tent . 

* It can be determined when a specification is complete 
(when the model has been fully defined al the chosen 
level of abstraction). At this point, ii should be possible to 
answer all questions regarding pertinent behavior 

Neither of these properties holds for informal techniques. 
In a normal software lifecycle it is not until the code is 
written (the first complete formal description) that many 
questions regarding behavior can be answered with any 
certainty, either by code reviews or by testing. This is 
typically too late in the project, and contributes to many 
of the problems of software development, 

Many questions can be answered purely by inspection of 
the formal specification just as programs can be under- 
stood by examining code. However, formal techniques 
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also allow properties to be verified formally. This is ac- 

plished by stating a pan it ularh properly reared of 
Tin* system and Itoen proving rhat the specification satis- 
fies this property. 

Formal verification in this style is difficult and time-con- 
suming, and current sool supjK>rt for reasoning is ex- 
mely inadequate. In practice, it is not expected that 
■s of fori' s in de- 

llowever, it is always useful to understand how to 
consider properties formally even when carrying 0u\ 
formal, tot rigorously I 

As an example, suppose we wish to show thai all mes- 
sages in each of the system's mjrays are addressed to the 
owner of that tray. The properly can be stated in IIP-SL 
with (he clause: 

I V sy§. Mai t_sy stem ■ 

( V person G domlsysf ■ 
( V msg E {in_tray{laakup sys person^ 
personE recipientsfmsgl 

II) 

which says that for any mail system sys and for every 
person registered in that mail system, each person is a 
recipient of all the messages (msg) in that persons in_tray. 

This property can be easily disproved by construction of 
a counterexample— say a system with one user called A 
whose in_tray contains a message addressed to user B, 

What we actually need to show is that this is a property 
thai is guaranteed to be maintained by the operations 
provided. In other words, if a mail system is In a stale 
where no message lias been misassijmed lo an injray I hen 
the operations provided will not cause this to happen. In 
addition, since this property is clearly Irue of an empty 
mail system (OHe with no messages ). and mail sysieius 
;iri' onlv created by application of tfce operations de- 
scribed, then we know ihai for all achievable states of 
the mail system this will be true la proof by induction). 

The proof is trivial because the only operalion that, adds 
any values to the injray is the transmit operation, which 
clearly maintains the required property QlC argument for 
the proof runs as follows: 

• The initial stale of the system has the property lhal all 
usrr> Y\:\w rni|iK I rays 

• A user's injray is modified by the addition of messages 

lerated by mail for applied to this user 

• mailjor returns only mall that has the user in (lie renpi- 
ents Held 

• Hence I he properly is maintained. 

Proofs can be fully elaborated to the required degree of 
formality- However, ihis kind of semifonnal rigorous argti- 
menl is mud re common. 

Adding System Invariants 

If a propeiiy such as lhal jusl examined is true for ail 
achievable mail systems, it is useful to highlight it by siai 
ing that it is a system invariant (a property or relation- 
ship that must hold for all instances of a particular type), 
In IIP SL. this lan he done by modifying the type defini- 
tion. 



syrrtype MaiLsvstem A 
(Person 2* Trays J 
mv sys- 
( V user E domjsysj - 

( V msg E ifi_trayf lookup sys userl- 
user E addressed! msgM 

The definition of MatLsystem is similar lo the earlier defini- 
egit that a logical constraint has been added. This 
-traint is specified by stating that the logical expres- 
sion following the * is true for all possible states of the 
mail system sys. The logical expression states lhat ihe 
only messages in users* injrays are messages that are ad- 
dressed to them. 

The type definition with the added invariant asserts that a 
mail system must never get info a state where the invari- 
ant is false. It is required that every operation on the mail 

em does not break this condition. As we have seen, 
Has is true of all the operations SO far defined. In addi- 
tion, the definition of each operation can assume that the 
invariant holds when file operation IS called, 

hi fact, another invariant property exists for the mail sys- 
tem. This is that the outjray and pending_tray of a person 
can only contain messages that have (hat person as the 
sender. Hence the system type definition with the com 
plele invariant is: 

syntype Ms'N„systern = 
\ Person ^* Trays) 
mv sys- 

( V user E dom(sys|- 
( V msg £ injray (lookup sys user) 
user £ recipients(msgj) 
A 

1 V msg e out Jraydookup sys used U 
pending Jraytlookup sys user) user s senderlmsgl) 
I 

Analysis of the system and Its intended behavior may well 
reveal other invariant properties, but lor Ibis example 
specification these two will suffice. 

Keasoning is, of course, not limited to invariant proper- 
lies Other aspects of behavior can be analyzed. For ex- 
ample, the Specification has made certain assumptions 
about the behavior Of ihe system when posting a mail 
message thai contains an unregistered recipient The fm- 
mal specification gives a way of deciding tf assumptions 
such as these are reasonable. 

Limitations of the Specification 

Now i bat we have a have a specification of a mail sys- 
tem, there are several problems with (his mode) of a mail 
syslem. 

The model is lacking many important operations. It 
sin mid be clear that many more operations on the mail 
system could be added. However, for this paper relatively 
tittle benefit would be gamed so ih*' additional definitions 
have been left out for the Sake of brevity. 
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Specification of State in HP-SL 



HP-SL is primarily a functional specification language There is no direct concept of 
state variables wrthm tiie language. Hence there can be no notion of side effect, 
no concept of sequence, and no statements— only expressions, This adds to the 
clarity of specifications and facilitates reasoning. 

This does not mean tfiat we cannot describe state dependent systems «n HP-SL. 
State-related behavior can be modeled m a completely straightforward way. If we 
analyze the use of state variables sn programming languages, we see that there 
are just two distinct forms: 

> Local variables used m algorithms to evaluate the result efficiently 

> The system state, which is the persistent data that is kept and used by the system 
operations. 

The first of these uses is not relevant when dealing with the style of specification 
used m HP-SL HP-SL specifications make assertions about behavior with no con- 
cern for run-time efficiency. Efficiency is seen as a separate concern which is 
addresser] during design, not specification. 

However, system state is useful because it gives a vety natural style of describing, 
designing, and implementing large numbers of systems. To specify system state in 
HP-SL. ail that is necessary is a type that can represent ah the information neces- 
sary to specify the operations on the system Hence, every possible state of the 
system can be represented as a value of this type. 

Every state -mod if ymg system operation is dsfmed as a relation between the rmtial 
stale (the state existing before the operation), any parameters necessary for the 
operation, the result returned by the operation [If any), and the final state (that 
resulting from the caii of the operation) 



The typical farm of such a re'ation is. 

re In a_f elation : System x .,. 
is a_relation (sys r ... , ays') 



* System 



By convention, s-ys is the name used for state and the initial value of the state is 
distinguished from the final value by the use of an apostrophe I'j. Thus, the final 
value is called sys h 



The model is inadequate because it does not deal with 
Issues O t c on cu rren c y. The spe c i. fi C a lion ass u mes t hat 
every operation on the mail system is complete before 
another can start. This is clearly not a reasonable restric- 
tion. Why should users not add messages to their pend- 
ing trays while others are transmitting the messages in 
their out_trays. 

This concurrency could he modeled at the expense of 
greater complexity in the specification. If the purpose of 
the specification is to reason about concurrent behavior, 
then this should be done as a separate step. 

The model is inadei|uale because it does not deal with an 
unreliable communication medium. 

None of these limitations invalidates the specification 
when considered as a specification of message addo ss 
trigj nay manipulation, and so forth. It does describe an 
abstract vu>\\ of some properties of the mail system but 
ii makes no claim about defining all behavior, 

In principle, very detailed models of systems and their 
properties can be defined. However these are rarely the 
best specifications to wriie ai least as ait initial system 
specification. In pai1iciil.tr. detailed specifications can 



mask overall abstract behavior and make it harder to 
reason abutu a system's properties. It is pari of I he skill 
of using notations such as IIP-SL lo decide which aspects 
of the system are important and which may Safely be 
deferred. Specificalion can be used in just those areas 
thai are considered likely to be difficult. The specification 
process may be repeated at several levels of detail and at 
different points in (he project. 

Refinement 

An important feature of using formal specifications is the 
ability to write specifications of the system in increasing 
levels of detail and to reason about the relationship be- 
tween such specifications. The process of constructing a 
more detailed specification front a more abstract one and 
demonstrating their correspondence is called refinement. 

Refinement is rarely done in practice for whole systems 
(it takes too much time) but an abstract specification of a 
whole system, followed by del ailed specifications of one 
or more key subsystems is [practical and useful. As with 
reasoning about system properties, reasoning about t&£ 
correctness of refinemeni steps can be carried out in an 
informal or semifomial manner as required. 

In refinement, one of Ihe key principles is to show that 
ihr properties of the abstract spe eifi cation are maintained 
in ihe second, more concrete specification. For example, 
in moving to a more concrete representation of messages, 
one might expand the definition of a message to include 
Other fields. This moves the abstract specification closer 
to a representation that can be modeled directly in an 
implementation. So T for example, a sequence could be 
used instead of a set since ii is typically easier to imple- 
ment a list in a programming language than a set. 

type Mew message ^ 

Unew message • 

inew_sender: Person, 
new_recipients: Seq Person, 
creation_date: Date, 
sending^date: Date, 
text: Contents 
I 
1 

The correspondence between this model for a message 
and the one given earlier lor type message is demonstrated 
by the use of a function (technically called a retrieve 
function) which shows how the new type represents the 
old type. This is part of a process that shows that the 
more complex type is capable ol representing all possible 
values of the more abstract lype. 

tn retrieve_message: New message -* Message is 
retrieve^ messa geln EW_msgt 
return msg 
post 

sender(msg} = new senderlnew_msgl 

A 

recipients(msg) - efemslnew redpients(new„msgH 
'■• 
conteotsimsgl = text(new_msg} 

Given this, the process of demonstrating the correctness 
of this step continues with showing that the new specifi- 
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cations operations behave equivalentlv to those <>• 
original abstract doe Unfortunately, this is too complex 
to demonstrate and explain in an introductory paper 
In principle, refinement could continue all the way to 
Code, thus ensuring thai the final code implements the 
original - <>n. Unfortunately the technology need- 

ed to help with the proofs is not yet available and so this 
is not feasible fnr wfac 

tl does give is a definition of what it means n> imple- 

lions This definition 
can be informally cheeked as pail of thi soft- 

ware construction. 



iiing such specifications forces the specifier to con- 
front quests ins regarding the behavior of the system that 
might othenv ise be overlooked 

* The ability to reason about the specification is important 
u * provide a firm > specification reviews and for 
subsequent coding. 

* The cla d&catton i » f uncierst anding ol ■ ■ d by 
th* - riate abstractions is an essential 

stem definition 

* The notation provides a clear and unambiguous sta 
mem of behavior, without the confusion of discussing 
mechanisms and algorithms. 



Conclusion 

This paper has shown how HP-SL forma] notations can be 
used in the specification process b\ discussing a simple 
example. In partii i 
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Specifying Real-Time Behavior in 
HP-SL 



Using the event and history specification features of HP-SL, the software 
for a real-time alarm monitor is specified 

by Paul D. Harry and Tony W. Rush 



Many of the systems that IIP builds must be able to ex- 
hibit real-time properties sueh as concurrency. Therefore, 
ii is important to be able to specify not just what hap 
pens hi a system, but also when events happen. This pa- 
per provides ail example of using a feature 1 of the IIP 
Specification Language (HP-SL J called hislory types to 
specify an alarm monitor for an electrocardiogram (EGG). 

Alarm Monitor 

As part of the efforts to work vsiih divisions in HP T s Med- 
ical Products Group, we in the applied methods group of 
HP's Bristol laboratory were presented with the following 
Specification for a raise alarm system monitor (alarm 
monitor) for EC ft measurements. 

* The system monitors incoming EGG measurements and 
compares theiu with maximum and minimum limits 

* The alarm is initially canceled, 

* If the incoming measurement exceeds the alarm limils for 
more than a predefined limeoul (delay) period, the ahum 
should be set . 

• When an in-liuiils value is ivi-oi\ed ihe alarm is canceled. 

• The user can enler new alarm limits at any time. 

• There are initial (default ) limits. 

From this informal specification we can identify Huee 
states the raise alarm syslem can be in (normal, delay, 
and alarm), and two values of the alarm j alarm set and 
alarm_cancelerj). A constant, t_delay, is the time for which all 
the measurements have to be out of limits before an 
alarm is raised. Fig. 1 shows the relationship between 
measurements, alarm limits, states, and the alarm values. 

Alarms, Measurements, and Limits 

From the natural language specification, the following 

HP-SL data type can be defined: 



Alarm Values alarm canceled alarm set alarm canceled 



Slrtte 



Normal 



Delay Alarm 



Normal 



Time 



Measurements In Limits Not m Limits In Limits 

Fig. l. Measurement tvahn 



syntype Atermjimits ^ Real x Real \w (min, max) ■ min < max 

This type consists of pairs of real numbers, with the add- 
ed constraint that the firs! member of the pair must be 
strictly less than the second. This is a use of Hie tuple 
data type with an invariant* subtype. Therefore, the value 
j!i, 100.5) is of type Alarmjimits but Ihe value (£), 2.~<: \s 
not. 

There is some default value for the alarm 3 i rails. We shall 
merely state that this constant is of type Alarm limits, bill 
nol give an actual value. This is an example of ander- 
spe< ifi< at ion. 

val defaurtjimits: Alarmjimits 

The alarm itself can be either sei or canceled. 

type Alarm ^ d alarm^set H I [[ alarm_canceled Jl 

The lype Alarm is modeled as an enumerated type with 

the two (distinct) values alarm_set and alarm_tariceled. 

The incoming measurements, which are constructed from 
the ECG wave, are simply real numbers. 

syntype Measurement A Real 

A given measurement is either wiihin the alarm limits or 
not. This can be observed by I be function injimits. 

fn injimits : Measurement x Alarm Jimits -* Bool 

is 

injirnitsivalue, (min r max)} 

A 

mm < value a max > value 

So h for example, the expression: inJimrtsIS, (2, 9,51) is true, 
whereas the expression: in_lrmits(1 , (2, 9.51) is false. 

The raise_alarni Process 

We can Specify litis system by the raise_afarm process. Fig. 
2 is a first attempt al drawing a data flow diagram for 
fins process. The process takes two inputs (the alarm 
limits and live measurement) and produces one out pin 
[Ihe alarm stale). In the data How diagrams of structured 
analysis, the flows consist of individual values. For exam- 
ple ihe mea5 flow consists of individual values of type* 
Measurement 

The behavior of Hie raise.alarm process depends not just 
on one measurement, but rather cm many previous mea- 

-inl is a pmpem iha* rcusi always be maintained tor 3 particular type. 
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Values 
I 



Fig. 2. Inil 

surcments. In other uords. the behavior depends on the 
entire hisiory of measurement values, In structured analy- 
sis the necessary historical information would have to be 
•1 within process raise_alarm, which would he done by 
decomposing the process Into subproeesses and a daia 
store. Fortunately, there is a more direct way of specify- 
ing the behavior using a style of specification known as 
his t ory s pec i fi eat i on . In st ead of d e n i n g a p f i n sess 1 1 1 
terms of the current values on Us data flows, hisioty 
specifications define the process in terms of all the past 
values on the flows, dial is, in lerms of histories of val- 
ues. 

History Types 

There are two forms of histories, evcin histories arid stale 
histories, each reflecting different tune properties. 

Event Histories. Event histories model flows that have 

events occurring ai discrete times. Examples of event 

histories include: 

Pulses from a revolution counter on a car drive shaft 

I lebils and credits on a hank account 

Button presses 

The incoming measurements in ihe E0G alarm system, 

Even! histories are characterized by ihe significance of 
duplication. For example, two debits to a bank account 
{even if they have the same value) are different from one 
debit Event histories can be illustrated hy a marline as 
shown in Fiji. & 

The timeline diagram shows: 
i The stan lime and end time of Ihe history. In Fig. 3 the 
stad time is in. and die end time is lo. This gives Ihe time 
interval over which i his history models ihe events. 
The events, shown as X symbols. Each eveni lias a value 
fshOWIl above Hie hue) and a time (shown below the 
hue j. For example, in Fig. 3 there is an eveni w nh value b 
at lime t3. 

Event histories are modeled hy tlte IIP SL lype conslmc- 
EOl Hist„, For example, a history &i measurement events 
would have lype Hist e |Measurement). 

The expression times(h) is the set consisting of all I In- 
times of events in history h Using the history K defined 

iji f-'ii: ■; 

times(hJ = { \2 t t3, t4 } 



■*■ Time 



Fig, 4- \ state 

The operators start e and end e return the start and end 
times of an event history. From Ihe example history in 
Fig. 3. 

starts h B I ~- tO 
end B (h e ) - 15 

Given an event his; on ft. we can find the value of the 
most recent event relative to some time t using the ex- 
pression previaus_evem(h p t). The result is undefined if there 
is no event at or before time t. Returning to The example 
hisiory: 

prevkius_everit(h e , t3) - b 
previous„event<h eH t7> = b 
prevH3us_event<l'y til f* not defined */ 

Finally, a lime range can be checked using the operator 
in_interval e . For example, the expression 

t 'injntervale h 

icsis whether a time i i> within the range of times cov- 
ered hy the history h. From Fig. 3, 



t7 'in_interval t> fi 
t6 'in interval n P 



TRUE 
FALSE. 



Time 



i [J 



Fig. & \n event history, K 
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Stare Histories. State histories model Hows thai always 

have a current value. Examples of state histories include: 

Distance traveled hy a ear 

The balance in a hank account 

The current condition of a switch {eg., on or off) 

The alarm limits in the ECTi alarm system 

The Mali" of the alarm in the EGG alarm system. 

State histories are characterised b\ ihe Insignifieancc of 

;ihon. For example, if the bank balam ; is overwrit- 
ten twice in succession witii i f o ■ same value, ilus is indis- 
tinguishable from overwriting one& Furl her, slate histo- 
ries always have a pOSSlblv undets|ie< ified initial value. 
State histories nu\ be illustrated hy the graph shown in 
Fig- I. 

State histories arv modeled hy the llT-sb type eousmictor 
Hist,; and just like evenl hisiMiies state histories have cnd- 
point operators written as: stan 5 and end a . Tlie current 
value of a state history is found hy the expression h@t. 
Since slate histories always have a current value, this 
operator can he applied a I any lime within Ihe eridpoinis 
uf the hisiory. The following formulas hold for the hisloiy 
illustrated in Fig. 4. 
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<n h H»st t (Event) 






A 
out),: Oulpulf, 



Fig. 5. A count process. 



start s (h s l = tl 

end. s {h s ) = t5 

h s @ t7 = b I* at time t7 f h 5 has value b */ 

h 5 @ t4 = b 

h s @ t8 - c 

( V t; Time sat t3 s t A t < t4 ■ h s @ t a b) 

Note thar Bis use of sat on the last line constrains I to be 
beiweeu vi and 14. 

Specifying Processes 

In history Specifications processes are specified by relat- 
ing entire histories of inputs to histories of outputs. In 
Fig. 5 the process count has inpui of type Hist 6 (Evenil, and 
an output of type Qutput h . The inpul models a slreaiu of 
evenis. The count pnn-i^s hut puis a eonlinuously updated 
count of the number of input events received, Since I he 
output is continuously updated, it is modeled hy a stale 
history. The following invariant ensures dial die initial 
value of this history is zero. 

syntype Outputh = Hist 3 i NatO ) inv h ■ h @ stanch) - 

l ^Siilg an 1JP-SL relation the count process is specified as 
follows: 

rein count : Hist P (Eventf x Output^ 

is countj irih, outJ 
A 

lei 

val now ^ end e (in h ) 
in 

outh @ now = nLimber_oLevents(in h ) 

endlet 

The local value now is set to the end time of the history 
of input events The left-hand part of the main expres- 
sion, out h @ now, is the current value of the output state 
history, The right-hand pan. number of evems(in h ), is the 
number of events in the input history. 

This is the usual form in which we present history speci- 
fications. However, (he history specification alone does 
not say enough. The output history is only partly defined 
because we have defined its value at the end lime, bm 



have said nothing about its values at earlier times. We 
really want tin relation between the eurreut mil put value 
and the number of events applied throughout the output 
history. To do this we should surround the above relation 
with a universal quantification (V, read as "tor all") over 
all times along the histories. hortunaleiy, ihe nolarion 
used in historj Specifications does this for tree, so there 
is no need in write n OUlSelves, 

The overall meaning of the count process specification is 

therefore: 
At any lime, the output history of the system (out h ) is 
correct With respect to the given input history (in h ) if 
the current value of the output history equals the num- 
ber of evenis in the input history. 

Using the Histories 

Fig. 6 shows the data flow diagram for the raise_alarm pro- 
cess with the correct types on the data flows. Dotted 
lines arc 1 used for event histories and solid lines for state 
histories, 

The type definitions for the input and output histories 
shown in Fig. fi are defined as: 

syntype Measurement^ £ Hist^Measurement) 
syntype Limits^ 4 HistJAIarmJimitsI inv h ■ 

h © start s {h) s default limits 
syntype Aiarm h ^ Hist 5 ( Alarm) 

Note that the types LimitSh and Alarm h are declared to be 
state histories, whereas the type Measurementh is declared 
to be an event history. This is a suitable modeling choice 
because there are initial values for the alarm and both 
alarm limits, whereas there is no initial value for mea- 
surements. Indeed we shall see that one ol the functions, 
in_ljmits h , needs to test whether there have been an\ una 
surements before a given time. Such a test is not mean- 
ingful for a state history 7 . 

We can now start to define the process by the relation: 

rein raise_alarm : (IVIeasurementf, x Limits h ) x Alarm h 
is raise_alarm((meas P limits), alarm) 



limit),: Limits}, 




mess* Measurementh 



A 
alarm*,. Alarrn,, 



Fig. fj. Data rl'-'W diagram OJ r 1 1 1 raise_alarm process with tl ■ 
data Q 
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History Specifications 



The ECG alarm example stows onty a small pan of the power of history spe 

Unified Graphical Notation 

:'ions 
are provided for the most commonly used process specify 

Composition. ft .. 3sedSjgetr»- : ■ '/stems For 

example, we could ado processes to the ate- 

and to veto r ; feature is illustrated oy the composition diagram 

Rg 1 

Specification Styles, fhe state and operai specification used for the 

mail system (see page 32) can tie history specifications. For 

example, the composition diagram for the mail system is shown in fig 2 

The following guidelines could he used to determine which specification style to 

i Use state -based specifications when: 

T ne system is similar to a database It is surprising how many systems 
can be partitioned into a central data store accessed by read and 
update operations. 

"he system has few properties dependent on time 
Tie structure of the system is sufficiently simple not to need a graphical 
index to ihe system 








delete _ operation 






Fig. 1 ;.in n-u : on -jiagram forthe alarn. 



new mtsiage user message user message 

Fig. Z. •/.'■ pCSftta diagram far the mail System 

• Use history specifications when: 

The system has many properties dependent on time 
: The hierarchical structur-ng of oata few Diagrams is acequate. out their 

amr -Mtations are not 

: The system is structured into a cote '- fringes 

Implementation route. There is a systematic implementation route from specifi- 
cation to code via structured design. This route consists of five steps. 

• The starting point is the history specification tfl which processes relate whole 
histories of values 

• The history specification is 'reared as a classical data flow diagram and trans- 
formed into a structure chart. This structure chart will also be in terms of whole 
histories. 

» No implementation can handle histories, so each nistory must be replaced try the 
data that needs to be stored For example, in the count process the history of 

replaced by a count so far The result g known as the reduced 
design 

• The reduced design is optimized, 

• Module specifications are written This is usually only necessarv when oo limita- 
tion has made it hard to understand the modules from the original i i 

cations. 



Detecting Out of Limits Values 

Mi an earlier section Mtat described alarms, measurements, 
and limiis a Boolean fund ion, injimits, was defined whicb 
Is irue when a given value of the ECG measurement is 
between given alarm limits. The alarm monitor's behavior 
depends nol jusfl on whether the currem mgasusenients 
are ni limits, mn also on whether older measurements ari 
in limits lb do IfiiS we define a function mjimitsh over ih<- 
histories Measurement), and Limits*. This function iviunis 
TRUE if. at a given time t, the measurement is in limiis. or 
if there have beten r>o measurements, 

fn inJimitSh : Measurement * LimitSh * Time -* Baal 

is in limitShlmeas, limits, t) 

pre 

II m interval meas) a jt 'in_mterual s limits) 
A 

{ 3 tl & times(mBas} ■ tl 
in_limitsjprevious_eventfmees, t) r limits $ t ) 



The preeojulilion list's the Mint "lions 'in. interval,- and 

r in_interval, I (Sure that ihe histories are defined al the 

given lime, t. 

Deciding inhere have been an> measurements yet is 

done M> Ehe expression: 

I 3 1! ,l€ timesimeasj ■ tl s t) 

which is true just when there is at least one even! al 
some time tl in the history mens earlier than time t. (The 
exisienlial operator 3 is read as their exists" QT "there 
exists one or Rior©*) 

The function returns a ddanli value of true ii" then 1 are 
no measurements before 1 1 >•: given time t. ff there are 
earlier measurements, Chen ihe value ol the current rtiea 

suri'int'Ml is tnuml hy OSing the previotjs_.event operator The 

cunenl limits are luuml m> using the current value opera 
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tor (&) at the given time t. These measurement and limit 
values are rheii compared using I lie injimits function. 

Alarm Detection 

From the natural language specification for I he alarm 
monitor tl is clear that; 
» The alarm is only set alter all measurements have been 
outside the alarm limits for a given time 

• Any occurrence of an in- limits value cancels the alarm. 

The value ><j ihr time delay before out-of-Iimits values 
cause an alarm is not important to this spi ni'n -;i[ion. 
Instead, a constant is defined without specifying an 
associated \aluc 

va! t_delay: Time 

In practice, the value of this const ant would be eon- 
si rained to be wilhin clinically acceptable limits. 

For an alarm to be raised ai a particular time, culled now. 
the value of the measurement history must have been 
consistently mil of limits for a lime t_delay. Hence at any 
particular lime, a key value is the portion of the measure- 
menl history occurring between now and now t_delay. hi 
fact. Of most importance is the value Of Hie function 
injimitsh at all limes between the interval now and now - 
t delay. Informally, an alarm will be raised only if in_1imits h 
is FALSE at all times in this lime Interval, So. for an alarm 
in hr raised al lime now, Ihe following enndition should 
be TRUE. 

iV l. Time sat Inow - t_delay) < t A t < now • 

^ inJimitSh( meas, limits, tl] /" - = unarv operator not*/ 

Tins is not quite enough since it fails To hike inlo account 
the behavior of the system when it stuns, thai is, when 
now - t_rjelay £ startjime, The normal wa\ to spft il\ such 
a condition in HPSL i* to use the existential qtiani iIkt 3. 
In lorn tally we can say that an alarm condition exists if 
{arid only if) the system has been operating for at least 
time t_delay, and for all times between now and now - t_delay 
the measurement was not in limits. This can he expressed 
formally as follows: 

( 3 t s = (now - t delay! sat t 5 > start_time • 
( V t: Time sat t s ^ t A t ^ now - 
-> injimits^f mess, limits, t )\\ 

This expression is true only when we ran i on struct a 
lime u 5 ) that is t_delay before now and after I he start lime, 
such that the value of the measurement history is out of 
limits at all limes between t s and now. In particular, the 
expression cannot be true untiJ now is greater than t_delay 
(because no valid t s can be constructed}. 

Final Specification 

The following is the final Specification for Ihe raise_alarm 

process, 

• Alarms, limits, and measurements: 

syntype Alarmjimits 4 Real x Real inv (min, max) - min < max 
val defaijIt_lrmFts: Alarm Jim its 

type Alarm ^ f alarm_set ] I [ alarm_canceled j] 
syntype Measurement ^ Real /*ECG measurements from 
pattern*/ 

fn m limns Measurement x Alarmjimits — Bool 



is injimitslvalue, (min, max)! 
A 

min < value A max > value 

• History definitions: 

syntype Measurement^ ^ HJst B (Measurementl 
syntype LimitSh ^ Hist 5 |Alarm .limits) inv h - 

h f S startjlh I = rJefault_limits 
syntype Alarm^ 4 Hist 5 | Alarm) 

• [)ete< t ii it; * uit-of-limit values; 

fn injimitsh : Measurement^ x LimitSh x Time -?* Bool 

is in limitSh(meas, limits, tl 

pre 

|t In .interval^ meas) A (t H in_interval 5 limits! 

a 

i 3 tl e timestmeas) - tl ■£ tl 

in_limits(previous_event(meas; t), limits @ t } 

• Alarm detection: 

val t_delay: Time /* duration of out-ot-Fimrt values needed 
to raise the alarm'/ 

refn raise_alarm : (Measurement x LimitSh) * Alarm h 

is raise..alarmf|meas, limits), alarm) 

A 



let 



val now = end e (measl 

val start Jime = start P (meas) 



in 



\ 3 t s - (now - i_delay) sat t s > stsrt_time ■ 
1 V t : Time sat t s < t a t < now - 
- 1 in limitShfmeas, limits, t))| 
then 

alarm & now - aterm_set 
else 

alarm @ now = alarm_canceled 
endif 
endlet 

Exploring ihe Specification 

One of the advantages of specifying a system formally is 

thai the specification provides an opportunity to reason 

about the system and Ihe consequences of En€ Hioi< es 

made. For instance, some of the Questions that can be 

raised about this example Include! 

Is the systems behavior at startup correct? 

What exactly happens when no BOG signal is received? 

What happens when alarm limils are changed? 

On startup, no alami can he raised This is ensured by 
ihe test in ihe if expression 0f raise_alarm being false- 
Hence the output value is alarm_canceled_ This would seem 
to be correct when evaluated against the in ton na I require- 
ments. 

When no EOG signal is received, the value of injimits^ is 
found by looking backwards in the measurement history 
for the last received measurement. Hence, if the last mea- 
surement value was out of range, an alarm will be raised 
after t_cielay. If the last value* was in range, no alarm will 
be raised. If there have never been any values, the default 
behavior of in_limits h ensures that no alarm is raised. 
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n limits are changed the function in_liinits h automati- 
cally uses tht> new value of the limits to test incoming 
values. An interesting case is when the limits are changed 
and no ECG measurements are received. In this case, the 
roost recent value on the ECG input pared with the 

new limits, This has the consequence that an alarm might 
be raised even though no new ECG data is received be- 
cause the limits have been changed. Is this the correct 
behav 

The answer i* that this is a feature of the product that 
needs to be decided. This qu I into the 

normal product requirements definition activity. The use 
of a more formal Specification highlights these boundary 
s at an early stage in the software development pro 

Conclusion 

Tills article has introduced the history data types of IIP- 
SL, and has shov^Tt how they are used in history specifi- 



cations io specify processes. We have found that in prac- 
tice this style of specification works extremely well in 
describing embedded systems. For example, see the ar- 
ticle "Formal Specification and Structured Design in Soft- 
ware Development" on pagf 

History specifications are an attempt to combine the best 
features of formal specifications said structured analysis. 
like structured analysis, they have ait accessible graphical 
notation that allows a large system io be decamp 
into a hierarchy. Like formal specifications, they have a 
rich data language and a fully defined meaning, and sup- 
port abstraction or underspecification. In addition, history 
specifications allows properties involving time to be stated 
very directly. A problem that might require a control 
specification, a data store, and several subproc esses in 
structured analysis may only require a couple of functions 
when using histories. 
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Using Formal Specification for 
Product Development 

In one product development project, the use of precise software 
specifications helped to uncover potential problems that might ordinarily 

be overlooked, and raised some interesting issues about using formal 
techniques. 

by B. Robert Ladeau and Curtis W, Freeman 



Karly tn t®89 a collaboration was set up between a proj- 
ect Irani ar the cardiac <arv systems (CCS) business unit 
at HP's Wall ham Division and i lit* applied methods group 
(AMU) at Hi 1 Laboratories in Brisioi. Engiaiid The coilab 

oral Kin involved pinjoor engineers from both groups, with 
comniiiiiicnlion Inking place through :i few on-site v Isil.s 
and a lot of ' ele< Ironic mail correspondence. 

Al a very high level, the goal for hodi groups WM to im- 
prove tlie quality of I he soil ware Ilia I was to be devel- 
aged, There were additional goals specific to each group, 
We al Walthani were interested in adding more discipline 
to OUT Software development process and learning mm. 

about formal methods. Goals specific to the amo were to 
transfer die laiest software development technologies to 

Other MP divisions hi our case this meant enough I rain 
ing and support in ihe HP Specitlf atton Language (HP-SLj 
to enable us to write our own formal specifications. In 
return, the AMG engineers would get feedback from proj- 
ects within HP product divisions specific to their research 
interests at [IP Laboratories. 

This paper reviews the res nils of our collaboration involv- 
ing Ihe ir iinn I action and use of formal specification dur- 
ing the development of a medical product software en- 
hancement. We discuss the lessons learned during this 
process of introducing an advanced software engine* ring 
methodology into an R&D environment. We also describe 
The specific achievements ami problems dtal were experi- 
enced in using formal methods to specify puns of the 
so f tw a re lit i ic t i 01 lalil y. 

The Project 

The project at Wail ham was created lo add a new feature 
(ST segment measurement ) to an existing medical prod- 
uct, The product is a bedside monitor that is use* I (n 
monitor vital signs ol patients in intensive care units and 
i j] ^ rating rooms. ST segment measurement is a measure- 
ment of the change in a portion of a patient's electrocar- 
diogram <ECG> called the ST segment (see Fig. 1 i, 
Changes in the ST segment of a person's ECG can indi- 
cate reduced blood How (ischemia) to an area of the 
heart These changes mav be clinically significant in cer- 
tain patient populations specifically patients who have 
had heart attacks. Changes in this portion Of an ECG 
waveform occur slowly, can be asymptomatic (produce no 
pain or discomfort), and are often hard to detect by (he 



r"\ 




ST Elevation/Depression 



ST Point 



Fig, 1. EGG lot one wdiac cycle (one heati beat), 

user (physician or nurse), IK providing this functionality 
in a paiieni monitor, we aim to supply the user with an 
early warning that one Of these episodes of silent isch- 
emia is occ lining. 

Using HP-SL 

As described in (he ariicle on page 24, HP-SL is a not a 
turn for describing systems and components in an ab- 
siracl yet precise manner, allowing a user to focus atten- 
tion on whal ;i swiil should do and defer details 
relating Eo how to build tin- s.vslrm until later stages of 
development. During (his collaboration, we used I1P-SL lo 
create abstract yet precise descriptions (models} of vari- 
ous bits ami pieces of the software to better understand 
the desired behavior early in the development process. 

The software developed on (his project continuously mea- 
sures a portion of an lv( G Complex called Ihe ST seg- 
ment. Modeling the ECG wa\e at an nhslnul level makes 
il easv to understand and capture [document \ essential 
properties of an ECG wave, properties that must exist for 
valid ST measurements to be made. 

Modeling the ECG Wave 

The EGS data that is input to the ST segment measure- 
ment algorithm is basically a stream of voltages (sec Fig. 
2), along with some configuration information such as: 
The voltage source (the lead) 

How much tillering has been done on the signal dn 
bandw kith) 
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* Wave content information such as which voltages repre- 
sent usable patient information and which are invalid (t)ie 
validity 1 

# Time. 

The ST algorithm uses this incoming ECG data and Other 
informal] mm to find and measure the ST segment of an 
ECU wave. If an ECG wave is measurable, an ST m 
sureruent will be produced. To capture the notion of mea- 
surabihiy it is helpful to he able to look at the problem 
at an abstract level without euneems about resource lim- 
itations, BCG data is receiveii as a sequence of wave 
samples that includes all the information mentioned 
above. Therefore, an ECG wave sample can be viewed as 
the cross product of these elements, and can be modeled 
using an IIP-SL record as: 

type Wave_sample ^ 

[wave_sample E> 

[voltage : Ecg_voltage, 

validity Validity, 

lead : Lead, 

bandwidth: Bandwidth, 

time ; Time) 
I 

An Er<; wave can Mien be modeled simply as a sequence 
of wave samples: 

syntype Ecg_wave £ Seq Wave_samp!e 

Now the notion of measurahilily ran be specified. An 
EGG wave is measurable if all of the wave samples are 
valid, have a specific bandwidth {QM Hz high-pass), are 
derived from ihe same lead, and are continuous mi lime. 
Using HP-SL ibis property can be expressed as a relation- 
shi]) involving the elements of a wave sample. 

rein measurable : Ecg_wave 
is measurable (ecg_wave) ^ 

{ V (wv_samplel € elems (ecg.wave)). 

validity(wv_sample1| s valid 

A 

bandwidth(wv_samplel) = hz_pomt05 

A 

\ V Iwv.samplel E elems (ecg wave}), 

Ieadjwv_sample1} = leadlwv sample2)) 

A 

continuous (ecg wave)] 

Tin- final relatnm. called continuous, Specifies the remiire- 
menl I bat ibe wave segment must be a continuous stream 
of wave samples (no gaps). This relation simply slates 



ihat if two wave samples occur one after the other in 
sequence, the time associated with \hv second wave sam- 
ple is one time unit after the time associated with the 
first sample Hfttfe HP-SL this notion is expressed as: 

rein continuous : Ecg_wave 
is continuous (ecg_wave) 4 

(V|iE inds (ecg^wave), j E inds (ecg„wave)l 

time(ecg_wave(i)) =* successDr(time|ecg_wave(i))|} 

The HP-SL operator inds returns the indexes of a se- 
quence. 

In our products an Ki G \v;iw [g i>jiit -jiIK implemented as 
a stream of data that consists onfe of voltages. Because 
of resource limitations [CPU time, BAM), the Jiher in- 
formal ion (validity, lead, etc I is input via separate data 
streams where the data is updated less frequently. This 
works fine in an implementation it the developer knows 
what the relationship is between the streams of voltages 
and other data, so that changes in validity, for example, 
can be associated wish the correct voltages, Problems 

arise if the developer hasiM learned, or forgets, these 
implicit relationships. 

The model shown above makes these relationships explie- 

a For example, (he reiiuhvmeni thai all wave samples be 
derived from the game lead has been made explicit and 
available for teviei* B3 modeling die problem at an ab- 
straei Level, implim relationships can be made expnoft 
HP-SL provides a framework for making important prop* 
erties explicil and increases the chance that an important 
propeny will be maintained across different Implementa- 
tions* 

A Problem Uncovered 

The process of understanding and specifying the notion of 
measmabihn uncovered a problem In an existing product 

An ST measurement is aelually made on a beat (see Fig. 

1). a beat is a portion of an B< <- w;iw thai represents 
the electrical activity present during one cardiac cycle 
(one heartbeat), When a measurement Is made, the corre- 
sponding beat is displayed to the user for review. 

En one ease the requirement that all Of I he wave samples 
dial make up a beat be valid was nut met. If a certain 

mixture of valid and invalid samples was present, the 
beat would mistakenly be considered measurable 14m 
result was benign nhe ST measurement was labeled inval- 
id), but if was possible to display a strange looking bead 



December 1091 Hou'trtt l'w -k;mi .Imimal 47 



)Copr. 1949-1998 Hewlett-Packard Co. 



for a short amount of nine Our effort lo capture a pie 
else, ;ti>srt;H i notion of measurability made this hidden 
problem visible for the fast time. 

Focus on Precision 

One benefit that v\r noticed from our introduction to for- 
mal si»r( ification was thai sun emphasis oti precision 
started to pervade our development process. We found 
that uncovering potential problems was pushed lo aji ear- 
lier stage of the development \ process than would have 
been the ease had wr not been focusing as much on pre- 
cise specifications. 

The primary function of a patient monitor is to transform 
the electrical signals coining from a patieni into informa- 
tion that is useful to clinicians, These electrical signals 
are transformed into streams of digital samples represent- 
ing a wave. This wave is analyzed and a numeric value is 
produced thai represents a piece 6i the information con- 
tained in the wave, stich as heart rate derived from an 

E<(» wave, or blood pressure derived from a blond pres- 
sure wave, This numeric value is called a parameter, 

In our case we needed to analyze three separate EGG 
wiiws and produce tfeee separate ST measurements. We 
needed to give the user Control over the ST measure 
mints both as a group (e.g., turn the ST measurement for 
all i hi' BCG waves on or off) and independently (measure 
the ST only on the second E('(i wave). This requirement 
lor both separate and combined controls was met through 
the use of a multichannel parameter The ST parameter 
has three channels (ST1, ST2 t STMj, with one ST value for 
each channel. 

The patient monitor also contains data management soft- 
ware thai provides the user with a trend of changes in 
U\r ST measurements. Depending on the on/off slate of 
the ST parameter and channels, ST values are stored or 
rejected by the data management software, To communi- 
cate this information, the ST software needs to maintain 
two fields in a message, a parameter on/off field and a 
channel on/off field. These two fields weir defined as 
Boolean fields within a Larger data structure Tin* 
associated textual description was: 

Parameter ON/OFF: Parameters may be switched off from a central 
task window ... This has no effect on the internal functionality ... 

Channel ON/OFF: Channels may be switched on and oft, hut the 
effect is as with Parameter ON/OFF: Processing remains unaffected 

We felt that our introduction lo formal specification 
helped us quickly not ire a potential problem, specifically 
the lack of an invariant in this description. HP-SL sup- 
ports the specification of invariants on data thai is being 
modeled, and when used in a data type definition, an 
invariant defines a relationship thai musl hold for all 
instances of thai data type, A quick look a) the descrip 
tion Of the data structure containing the above fields 
shows thai there is little discussion of any relationship 
between the parameter on/off fields and the channel on/ 
off fiehK 

We expected fcq see an invariant indicating that if the pa- 
rameter was in the off state then the channel must be in 



l he off si air. The lack of this invariant raised a warning 
flag. It turned out that the data management software 
received all three channels of ST measurement informa- 
tion, bill used only the parameter oiiuti HHd In deter- 
mine Mit Ihn or nol In store The information. When we 

turned a channel offbul left the parameter on ia reason- 
able scenario firom our pnini <>( view) the data manage- 
ment software would display ari ST trend with invalid 
data, since no ST measurements wete being made while 
the channel was in the oft state. We wme able foq resohre 
this problem through discussions with the trend software 
developer long before the product was released to cus- 
tomers. 

Similar ambiguous specification problems were encoun- 
tered in a related area — alarm handling. There was no 
clear description of the expected behavior of multiple 
alarms on multiple channels of a single parameter, M a 

rest ill we developed suit ware Thai W€ thought behaved 

reasonably. Afu i several unsuccessful attempts ai making 

our alarm bcha\ iot nialeh l\\r expected alarm behavior 

(the behavior of die existing alarm handling software), 
discussions with the alarm software developer again ted 

to resolution of (he problem before product release. 

[fa description is ambiguous then multiple users of thai 
description ran easily have different interpretations* If a 
developer eau provide a single, precise description (a 

model) of whai is In he implemented, then there is ai 
least an opportunity for the adequacy of the model to be 
tested through reviews, and ambiguities cleared up at the 
earlier stages of a project. The single, precise model may 
be wrong, bill at least multiple reviewers ean focus on 
the same wrung mode! instead of making incorrect as- 
sumptions abQUt an ambiguous model. 

Issues 

Any new process, no matter how great the benefits, will 
encounter some difficulty in gaining acceptance or reach- 
ing the poini where the benefits become real and tangi- 
ble. Introducing formal specification is no exception. The 
issues raised fall into two categories: learning and apply- 
ing forma] specification, and introducing a new methodol- 
ogy into an existing software development process, 

Learning and Applying Formal Methods. The issues related to 
this category Included 
• Differing learning curves for reading versus applying the 
modeling tools provided b\ HP-SI*. 

This problem is akin to reading versus speaking a foreign 
language, jflhe WOtfdS and syntax have already been put 
together by someone else, it is not difficult to follow 
most nj whai is written down. It is much more difficult 
lf> find the correct words and apply the correct syntax on 
ones own. A similar learning curve must fcfe overcome in 
becoming proficient at creating models using JIP-SL and 
it involves practice and making mistakes. Mistakes are 
nni eas> I flings to figure fcntO .i Schedule. 

A i iln start Of this collaboration the AMG gave a one- 
week IIF-Sb course lo our project team and software 
engineers from other projects. The goal of the course was 
to introduce formal methods and EIP-SL and to have all 
participants feel comfortable reading III'SL specifications. 
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This goal was reached. After the five-day course most 
participants felt comfortable reading HP-SL Bur mosr also 
felt that more practice was needed to feel comfortable 
writing HP-SL specifications. 

• Wondering if we could get the benefits of formal specifi- 
cation without learning another language or being so for- 
mal. 

This issue was raised frequently by ourselves and oti 
during this collaboration. As mentioned earlier, we fell 
that the focus on early problem analysis had both a direct 
and an indirect impact on our development effort. For 
example, the problem discussed earlier in which ihe prop- 
erty' of mcasurabitity was not met was found as a direct 
result of creating a precise specification. The second 
problem, ihe ambiguous parameter and channel descrip- 
tions, was quickly noticed as a result of our better under- 
standing of what it means to create a solid specification. 
Even though we are still in the learning stage, we feel 
that we need to master the use of this rigorous approach 
to software development before we can make die best 
judgments about where added rigor can be most produc- 
tive. 

• Using formal specification techniques to capture the es- 
sential behavior of an existing software implementation. 

We found it to be very difficult to use formal notation to 
document the behavior of an existing implementation and 
felt that it was one of the least productive ways for us to 
make use of formal specification. We attempted this for 
software that was being ported from an existing pioducl. 
Although this effort did in fact point out an existing prob- 
lem, the resulting specification was not very abstract and 
ended up liemg focused on hehavior thai vas a resull of 
our specific implementation rat Iter than on hehavior re- 
sulting from a more abstract view of the problem, 

• Understanding where increased formality is appropriate 
and where it is noL 

We found thai deciding whem to use formal specification 
was to some extent a judgment call Our projects are 
typically noi neat, tidy projects in which all of the re- 
i|uircmenH are precisely known :it the start and each 
software engineer has a clean sheet of paper from which 
to begin development. Many of the medical algorithms 
and associated behaviors (e.g., alarm handling) need to be 
reimplement ed (with enhancements) in new products, and 
there is often software in another product (e.g., data- 
bases, data review screens) that can be leveraged 

For example, to create a display for a new measurement 
in Ihe patient monitor, a developer typicallj ESes existing 
display software ;ls a template, a case in which (here 
doesn't appear lo be much of an underlying model lo 
capture. On ihe other hand, we did find thai the lime 

spent modeling the notion <>l lucasurnbility was useful. 

In this case, ihere appeared to be a signiflcani difference 
between the underlying model and the implementation. 
i hi i r software development efforts arc Ust termed soft- 
wan' reengineering, ami in this setting, we feel ihai for- 
mal specification needs to be mastered and use si as a 
iooi iii the discretion of the developer. 



Introducing a New Technology. The issues related to this 
category included: 
i The effect on project schedule. 

The use of this level of rigor for software development 
was new to us, and we devoted a lot of effort learning 

how to use formal specification for our tasks At the start 
of The project we scheduled time for taking an HP-SL 

se and workshop. In addition, we lengthened the pre- 
implementation stages of the schedule to account for 
what we thought idditional time required to 

ieam and apply formal speciBcattprL In retrospect, we 
underestimated how much time it would take to get com- 
fortable with this tool, and overestimated the number of 
portions of the software task that we thought we could 
specify Limiting our efforts to more manageable-sized 
portions of the task is one way we could have limited Ihe 
potential schedule cost 

► The need for up-front commitment of resources. 

On this project, as on most of our projects, two very pre- 
cious resources are time and money. The additional time 
in a project schedule allotted to learning a new software 
development method must he accepted by all parties. 
Also, the transfer of flus technology involved a collabora- 
tion between geographically separated groups. To collabo- 
rate means to work together, and this, despite modern 
systems of electronic communication, requires some face- 
to-face time. In our case travel was a necessary part of 
such a collaboration, 

i The difficulties in measuring the benefits of formal Speci- 
fication. 

Improvements in software quality can he difficult to mea- 
sure based on the metrics from a single software project. 
The slice of the project, design and code complexity, skill 
sets of the personnel involved, and tithe ^lolled to the 
project can all alfcel the metrics used to measure the 
benefits of a software process change. 

In Table I the metrics for our project are compared lo a 
project of similar complexity, Our metrics were good, 
and, although Ihere are a number of ways lo explain the 
data (e.g., th;sr defect density is proportional to test 
hours) we beheve thai the focus on up-front problem 
analysis encouraged b> Learning and using a forma] nuta- 
tion played a significant role in achieving a high-quality 
product. 
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Conclusion 

Many challenges must be faced in a collaboration to 
introduce a new methodology into an existing software 
development process. The biggest change we would make 
is to have all parlies view the collaboration as part or lh< 1 
project, iini something extra thai ran be done if linn 1 per- 
mils. < inly one schedule should exist and it should in- 
clude allowances for the collaboration. Only if the effort 
is given this importance and support can the people in- 
volved make it a true success. 

\\r used this collaboration as a vehicle for learning more 
ahoui the benefits and costs of tgstaig fonnaJ specification 

In practice it was very difficult to balance the introduc- 
tion of a new method with the need to produce a rela- 
tively simple software enhancement in a short amount of 
tune. We are convinced that there is much to be gained 
by using a formal specification language like [IP-SL to 
capture the essential behavior of the software machines 
that we design and build, and arc continuing to use this 
methodology in our development efforts. 
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Formal Specification and Structured 
Design in Software Development 

HP-SL history specifications and techniques from structured analysis are 
used to create a formal specification for a critical portion of the code for a 
medical instrument. 

by Judith L. Cyrus. J. Daren Bledsoe, and Paul I). Harry 



The . business unit ai I IPs Mr Minn villi- Division 

is responsible for producing medical instruments, souk of 
which have life-eriiieal functionality and require a high 
degree of reliability. These instruments are used in a high- 
tension environment hy medical personnel who are not 
necessarily computer literate and do not use the instru- 
ments on a dnil> basis. I Hit project team (from the ear 
diokygj business unit} is responsible for the development 
o| i mi- nt 'these I ire-critical instruments. 

Previous generations of the product are viewed as having 
defect-free software, but there is tio tbnnai way 10 verify 
this belief. The code in these earlier instruments was 
written in assembly language and is tightly coupled with 
the hardware Also, the code is considered to he hard to 
understand and is nol reusable, Tp remedy this situalion 
we established the Following goals for the new software 
in the product: 

Produce defert Tree, safely el it ira I software with fewer 

debug cycles 

(real* 1 software thai can he reused in the current product 

family and in future prodtirls 

Write unambiguous documentation that describes the 

safely -rrilieal tmiet innatity of die product 

Perform a validation process that compares the imple- 
mentation against (he specification 
Meet or exceed regulatory requirements for safety-critical 
product S. 

This paper describes 0111 experiences wiih using formal 
specification techniques to help implement a safety-criti- 
cal portion of the embedded software system for the 
instrument 

Why Formal Methods? 

During the project investigation stage, formal methods 

Were seen as an aid toward meeting our suit ware goals, 

v\e were convinced that wr should use the besl available 
met ht nis to achieve the high reliability needed lor our 
product We also saw formal specification as a way to 
ensure that product requirements were well-understood 
hy our eurrenl project train and by Future development 

beams or mainininers. The applied methods group CAMG) 
from I IPs Bristol laboratories provided us with informal 
lion aboul their work with a formal specification language 
called ill'SL (HP Specification Language) and offered to 
collaborate with us on tin- projrri. We saw the collabora 



tion as a way to establish expertise in formal men 
wit fun our division. 

The AMG had previously collaborated with another group 
at our division to use formal notation for a small part of 
die software ft>r an another product. Although thi 1 ^ was 
done on a wry small stale with limited success, there 
was enough positive unpad to influence management 
approval for OUT decision to use formal methods. Ttiis 
was a critical factor in successfully using formal methods 
because we fell thai we needed to include time in ihe 
project schedule for using formal spreificaliou let iuiiqtijgfl 

After deciding that we wanted to use formal methods in 
our development process, the first thing w r e did was to 
establish a collaboration plan between the IIP MeMinn- 
villc project team and the consultants from the AMG in 
Bristol This plan defined die roles of the collaboration 
team members and established a modified product life- 
r\rir plan i hat provided for the anticipated front end 
loading on the project schedule. Hue MeMinnville engi- 
nes and one AMG engineer actively engaged in ihe sate 
ty-critical software development effort Other collabora 
tii tn tram members participated in support activities, 
primarilv serving as reviewers. 

The Formal Specification 

The Irani derided thai it would he loo ambitions In nl- 
Iciiipl to Specify the entire software system formally, 
Therefore, (he system functionality was divided into safe* 

ty-rriUeal and iioiisaiefy critical subsystems Fig. 1 tllns- 
brates this division. The safety-critical code is located in 
ihe safety ei ii teal controller and occupies about HiK bytes 

of u<*\\ 

Based primarily on ihe produc is external specification 
(ES); tie collaboration team produced a complete formal 
specification of the safely-critieal part of ihe software. 
The formal specification provided a process model oi the 
system, specifying the relationship of inputs and outputs 
over nine fins model uses the IIP si, history specifica- 
tion (see arliele on page 10). whieh associates dala \alues 

with iinu\ thereby capturing inning constraints and speci- 
fying a data object's value for nil lime. This allows coiu- 
parisons between data objects at am- particular time, and 

e 
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Fig. 1. System arriiiUTMjre showing the separation between saH\ 
critical and rwitsafcty-criJicaJ functionality 

provides a history of what, has happened before so that 
new data values ran he derived from previous values. 

The specification is illustrated by a variant of data now 
diagrams. These diagrams look much like traditional 
structured analysis data flow diagrams, 1 ' - hui Ha* lm.-an 
ing of some of the symbols is changed to heller illustrate 
the formal specification. An example of one of these dia- 
grams is shown In Fig, 2> The data Hows between pro- 
cesses correspond to HP-SL histories, and the dashed 
lines, which indicate control data in traditional structured 
analysis data flow diagrams, are used to indicate optional 
data which is only present in some product family mem- 
bers. 



Early in the project, we decided to use two views of data 
to support a need for concrete ness at the external level 
and abstraction al an internal Level. The external view 
represents hardware dependencies such as the register 
bits that hold voltage information The internal view pro- 
vides a hardware independent representation of data for 
example, a data structure that just holds voltage vain 
regardless of the source or destination. The internal view, 
or core, specifies instrument functionality that is common 
to all of our product family members. This two-level view 
allowed us to separate and more abstractly specify the 
core of the system in a way that isolates it from the im- 
pact of hardware changes and makes it easier to reuse. 
Specifying the external view in a concrete way enabled 
us to correlate our design with the hardware design spec- 
ification. 

The formal specification includes an HP-SL data model of 
the external and internal views, HP-SL conversion pro- 
cesses which specify how the internal view of the data is 
derived from the externa! view, and a complete HP-SL 
specification of the system core process. The simplified 
top-level dam How diagram shown in Fig. 2 shows this 
data view and the conversion processes that convert, from 
the external view to the abstract internal view. Data flows 
(histories) coming into and going out of the diagram 
around the edges illustrate external Interfaces. The six 
bubbles around the outside illustrate the conversion pro- 
cesses with the internal data flowing into and out of the 
core process. 

A preliminary formal review raised many requirement 
issues, Initially we thought that the product's external 
Specification would be a sufficient source on which to 
base the formal specification. It turned out that this left 
many requirement issues ambiguous or undefined and did 
not provide enough information about the hardware and 
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timing to complete the specification. Following the pre- 
liminary review, project Team members were asked to 
provide timing diagrams and hardware and software inter- 
face documents, which would otherwise have been re- 
quired later in the project- Only when these were avail- 
able could the formal specification be completed. 

Implementation Route 

of the major benefits of using an HP-SL specification 

structured as a data flow diagram is thai the traditional 
route from structured analysis to structured design can, 
with modifications, he used. The data flow diagrams that 
illustrate the HP-SL specification drive the basic layout of 
structure charts. 

Fig. 3 provides a simplified comparison between portions 
of the traditional sin icnired anai structured design 

implementation route and the formal process specification 
implements nun route. In both approaches the process 
specifications define the system requirements and the 
module specifications define the design and implementa- 
tion of the system. 

In the traditional approach, informal process speeifiea- 
Huns define primitive processes [processes that are nol 
decomposed into bin her processes). Composite processes, 
and ultimately entire systems are defined by combining 
the primitive processes according to the data Row dia- 
grams. Module specifications describe the funciiunality of 
the individual routines that Implement the system. 

In the IIP-SL approach, a process specification is a pre- 
cise description of the transformation Gt incoming data 
into outgoing data. The modified data flow diagrams <Je 
fine how i he process specifications are combined to form 
the process specifications q! higher-level processes. As in 
the traditional approach, module specifications define the 
implement at ion routines. 

This systematic development mule pn serves IraceabiJttj 
between modules of Ihe implementation and processes of 
the specification. TraceabUitv permits verification of the 
implementation against the specification, and also allows 
test plan designers to make the best use of the specifics 
tion in defining tes< eases. The following siq>* ;in taken 
to implement this systematic development route. 

1. Start with an HP-SL specification and the accompany- 
ing d;im How diagram. Fig, 1 shows the data flow (Jia 
gram for one of the subsystems in the product. Remem- 
ber, dashed lines indicate optional data flows, which oxisi 
only in systems that have this oplioti installed. 

2. Treating the data How diagram Brian step I ;ls a classi- 
cal structured analysis data flow diagram, transform it 
into a hierarchical structure chart Fig. - r > illvisl rates a 
structure chart tor the example process. In this example, 
the second-Level modules correspond to the processes of 
the data How diagram, except for the process derive op- 
tion Jail are. Which has been moved to a lower level for a 
mora efficient Implementation, the data couples shown in 

represenl entire histories. 

3. No implementation can afford to pass entire histories 
between modules, a reduced design must be produced m 

which each history is replaced hy just ILie current value. 
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4. The stnirjure eliarl is optimized For example, modules 
are moved to different levels in the hierarchy (see the 
redueed structure chart in Fig. 3fc). 

5. If necessary, produce module specifications. Many 
times modules are closely related to the process specifi- 
cations, thus eliminating the need for module specifica- 
tions hecause the process speeifi cations are Sufficient 
However, if the optimization performed in step 4 is exten- 
sive, optional module specifications may be required (see 
Fig. 3b). 

6. Code is written from the structure charts, the HP-SL 
process spec ifical ions, and if any were generated, the 
optional module specifications. 
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Any historical information required must be explicitly 
stored in lueal stores (see I he hexagon-shaped boxes in 
Fig. 6). Noiice | hat two local stores have been added to 
module Time_puise. One keeps track o£ the time since the 
last pulse was fired antl the other keeps track of the time 
since die last externa] pulse was detected. 



The data flow diagrams and structure charts shown in 
Figs. 4, Bj and 6 provide a graphical representation of the 
software beblg developed using Ihe formal implementation 
steps described above. This section describes the develop- 
ment of the HP-SL process specification for I he process 
ttme_pulse. and the module that implements this process 
(labeled time_pulse_m in Fig. 6), The history and event 
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specifications described in the article on page 40 are used 
to develop the HP-SL specifiealion for this module. 

Pulses. Before considering the timejmlse process, we first 
consider pulses and the definition of an overdue pul*i 
pulse is a dataless event occurring within a specified time 
interval. A dataless or single-valued item can be modeled 
by the type Unit Pulses can then be modeled by an event 
history of units 

syntype Pulse n = HisUUnrt) 

If we have a history pulse n of type Pulse*, we can n-si a 
pulse at lime t with the expression pulse* @? t f which is 
true if and only if a pulse occurred at t 

A pulse is overdue if T from some time i_start to the cur- 
rent time row. there have been no pulses, and the system 
has been in state running. This is formalized by the expres- 
sion: 

I V i sat t_start <t \ t < now * 
-*pu!se h @? t 

A 

state* @ t = running 
I 

The time t_start is firejnterval.msecs (time between pulses) 
earlier than current liinc, or t_ start = now - fire_inter~ 

val msecs. 



As in the raise_3larm process (see article on page 40), we 
must consider the behavior just after startup. UTten now < 
firejnterval_msecs a pulse cannot be overdue. This behavior 
can be specified by an existential Quantifier. 3 I exists i 
which tests whether t_start Is earlier than the startup time- 
Combining the test for an overdue pulse with the test to 
verify thai t_start is earlier than the startup time, we get: 

fn pulse_overdue: Hist*, Pulse * Htst^ Stale — Bool 
is pulse_oveniuel putse r : 



A 
let 



val now ^ end s { state*} 
val start_time i starrest ate h ) 
val fire.jnterval_msec$ ^ 1000 1 rate h @ now 
i 
(3 t_start = now - firejnteryaLmsecs sat t_ start ^ 
start_t3me ■ 

(V t sat t_start s t A t < now 
-(pulse* ©7 ti 



state* @ t = running 



I 
endlet 



which returns a TRUE value when a pulse is overdue. 
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Time Pulse Process. The time_puise process generates 
pulses, and there are two pulse generation modes; de- 
ferred and fixed, In fixed mode pulses are generated peri- 
odically and in deferred mode pulses are generated only 
if an external source of pulses has failed. The process 
has four inputs: system stale, pulse mode, the required 
i*ii< of pulse generation (which determines the pulse in- 
terval), and the external pulses. There is one output — 
pulses generated when a pulse is overdue in either mode. 

The process specification for time_pulse is of the form: 

rein time_pulse: 

(Hist s State x Hist s Mode x Hist s Rate x Hi$t e Pulse} x 

I'Histg Pulse) 
is time pulsej (stateh, mode^ ratfih. externaLpulsehl pulse h | 



The occurrence of an output pulse ran be delected by 
the expression pulse_h @? now. However, we want to base 
pulse generation not only on when an output pulse oc- 
curs, but also when the pulse does not occur This can be 
achieved with the operator **, read as "if and only if." 

In fixed mode, an output pulse is generated if and only if 
there has been no output pulse for more than a given 
lime, that is, it' t he output pulse is overdue. This property 
can he formalized by the expression: 

pulse h @? now 

pulse_Qverdue(pjlsei v stated 

In deferred mode, there is an additional constraint. Not 
only must there have been no output pulse, but there 
must also have been no external pulse. 

pulseji @? now 

(pulse_overdue(pulse h<J stated a pulse_overduef externa l_pulse h , 
state ft) I 

Which test applies depends on the current mode (mode h @ 
now). 

Process Specification. The following is the final specifica- 
tion for the time pulse process. 

1 rein time_pu!se: 

2: (Hist s State X Hist s Mode x Hist 5 Rate x Hist e Pulse) x 



3: 


(Hist e Pulse) 


4. 

5 


is time pulsef tstate^ mode^ ratet v external pul 





let val now ^ end a | states ) 


7: 


in 


g 


puise h @? now <* 


9: 


cases mode h @ now of 


10- 
11: 

■2 


case [[ fixed {] then 

putse_overdue[pulse h < stateh) 
case [I deferred ] then 


\3 

a 
is 


pulse_overdue(puJse hr state.,) 
pulse_DVBrduefexternal_pulseh ? state^ 
endcases 


if 


endlet 



This relation specifies that a pulse occurs (line 8) in fixed 
mode (line 10) if the interval since the previous generated 
pulse (line 11) reaches the interval determined hv the 



rale selling in the pulse_overdue function. A pulse occurs in 
deferred mode (line 12) if lioth flie Interval since the pre- 
vious generated pulse (line K!j. and the interval since the 
previous external pulse (line 14) reach the interval deter- 
mined by Lhe rate setting in the pulse_averdue function. 

The test tor mode and overdue pulses (lines 94M) can be 
rewritten as: 

pulse overduelpulse^, stateh) 

A (modeh® now * deferred v pulse_overdue|external_pulseh r 

stated \ 

In lhe {' code implementation described below, this deri- 
sion structure is used directly on lines 25 to 30. 

Implementation. The following is ihe C < ode for imple- 
menting the time_pulse function. 

1: /include "ic_glotoal.h" 

2: typedef enurn { PULSE, NQ_PL1SE | tvpe .pulse ; 

3: typedef enurn { FIXED, DEFERRED } r_ype_nption_mQde; 

4: typedef enurn ( H(JNNING P STOPPED } type_opdon_state; 

5: extern unsigned_16 rate_table[l; 

6: type_pulse time_pul5e(external_putse- r mode, state, rate ) 

7: type_putse external^putee; 

8: ty p e_D pti o n_si ate state.; 

9; type_option_mode made; 
10: unsrgned_8 rate; 
11: { /*** Begrn Function ***/ 

12: static unsigned_l6 externa l_pulse_h_timer; 
13: static unsrgned_l6 pulse... hjtimer; 
14: type_pulse pulse; 

15: /* Reset the timers whenever the option is not running, V 
16: That way the timers will never expire and no pulses will be fired*/ 
17: if (state 1- RUNNING) 
16: ( 

19: extemal_pulse_h_timer = 0: 
20: pulse_h_tfmer = 0; 
21: pulse = N0_PULSE; 
22: } 

23: else /* optron is running 7 
24: { 

25: pulse = |( pulse_h_timer >= rate_table|rate]) f* pulse overdue 7 
26: && F and if not in deferred mode"/ 

27: {( mode f= DEFERRED! /* the ext. pulse must also he overdue 

■9 

28: I (external_pu]se_hjimer >= ratejablelrate])! 

29: ? PUtSE 
30: : N0_PUtSE; 

31: if (pulse £ PULSE) pulse_h„ttmer - 0; 
32: else if |pulse_h_limer <^ rate_tahle[rate:f pulse_h_timer+-i-; 
33: if (external_pulse A PULSEI external_puJse hjimer s 0; 
34: else if ( externa l_pulse_h_timer <= rate_table[ratel) 

external_putse_h_ timer++; 
35: } T end option is running '•' 

36: return(pulse); 
37:} 

The two calls to pulse_overdue are replaced by two timers, 
extern aLpulse_h_tTmer and pulse_h_timer (lines If* and 20), 
They are reset to zero whenever the state is no longer 
running (lines 17 to 22), or the corresponding pulse oc 
cure (lines :U rind 3S) f otherwise they are incremented 
('lines 32 a&d Ul 
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In the specification world we typically do not worry 

about size limits, However in an implementation, size lim- 
its are critical. If we repeatedly increment the tuner- 
could overflow Fortunately we are not interested in how 
big the timers get once they are beyond the overdue time. 
Thus the code stops incrementing ihe timers once they 
reach the rate table limit (lines 32 and 

Impact on Project 

The decision to use a formal notation for the safety-criti- 
cal software had a major impact on the project schedule 
and the way in which we performed our implementation. 
Because of the learning curve we found that front-end 
loading the project schedule was necessary to use formal 
methods successfully for the first lime, In our case the 
steep learning rune was offset by support from the HP 
Bristol leant. Thus, the overall impact on the schedule 
turned out to be minor. The benefits of a more complete 
external specification (ES). early requirements decisions, 
complete interface specification, and a good software 
design paid back the time needed to produce the formal 
specification. In fact, the completeness of design made it 
possible for one engineer to code the entire safety-critical 
subsystem in less than the usual amount of lime required 
to complete a subsystem of this type, 

The impact formal specification had on our implementa- 
tion is that it enabled us to identify and deal with prob- 
lem areas early in the project, contributing both to the 
quality of the final external specification and to hardware 
design decisions, Specific areas of this impact include: 

• To isolate the safety-critical software, we decided to use 
separate microcontrollers for safety-critical and nonsafe- 
ly-crilieal tasks. 

• The formal specification affected the structure and con- 
tent of the ES It exposed ES ambiguities and incomplete 
product definition, For example, the ES described normal 
system functionality, hut did noi define system behavior 
during abnormal situations, such as when multiple k$FS 
are pressed simultaneously. The specification forced us 
to deal with these issues. 

• Problem areas in tin 1 forma] specification identified the 
need for additional documentation (timing diagrams and 
hardware/software interface documents) early in the 
project, A timing issue that was mentioned in general 
terms in the ES was exposed by i he specification as a 
hazard These timing problems had to lie belter under- 
stood before the specification could hr finished. 

• The riefcd fci ' make firm requirements decisions for writing 
a formal specification thai could be reused in follow on 
products encouraged early definition of possible future 
systems and peripheral interfaces. 

• Work on the formal specification helped new team mem- 
bers team the produd requirements by exposing areas of 
1 1 1 isi mdersianding or ambiguity. 

• The formal specification identified important test cases 
and boundary conditions. Some processes have juvmndi- 

limis or invariants that define Come? rases, which had lo 

be tested. 
■ The formal specification helped in dealing with the regu- 
laiory process by helping define and plan for potential 
hazards (eg,, interprocess communication failure), 

• Software changes resulting town late hardware changes 
were easy to make and document 



■ The goal of maximizing code reusability for the safety crit- 
ical software was achieved. 

Problem Areas 

We did encounter a few problems during development. 
These can be classified as problems associated with the 
project development process and problems associated 
with using formal methods. 

Problems we found associated the development process 
were: 

• The external specification has a dual role in our division 
It serves hoth as tbe natural language requirements docu- 
ment and as an input to the business decision at the in- 
vest igatiomto-miplementation checkpoint meeting. This 
typically results in an ES that is not optimally suited to 
either, and in many cases does not contain sufficient de- 
tail on which to base the formal specif! ration. This prob- 
lem can be solved by producing, in addition to the busi- 
ness-needs-driven ES t a software requirements document 
that addresses functionality details, timing requirements, 
ami hardware and software boundaries* 

• Some interfaces were not tied down for a long time. This 
meant the formal specification for the interfaces had to 
wait, and sometimes this meant changing the core pro- 
cess when the interface was finally understood 

• The need for a concrete definition of the boundaries and 
interfaces when specifying only a part of the system was 
not initially recognized. Early availability of interface 
requirements would have greatly Simplified the specifica- 
tion process. 

Problems we encountered with using formal methods 
were: 

• When we learned HP-SL, we learned notation, but not 
abstraction or modeling. It is very hard to stop thinking in 
programming terms. A better grasp of abstraction would 
have helped in getting the niosl benefit from Ihe modeling 
power of formal notation, This comes with practice, 

• Clever paits of the HP-SL specification were intellectually 
pleasing hut not understandable bj "flu t members of the 

I earn or reviewers. 

• Formal notation does not provide early estimates pf rude 
sme and execution perfo nuance. This means that gross 
estimations (guesses) were used for ROM and RAM re- 
quirements — decisions that were needed early in Ihe proj 
cil As ii turned out. I hose estimations were remarkably 
accurate. 

Conclusion 

A number of factors were vital to the successful comple- 
tion of the formal specification and its usefulness in our 
software development. The most critical factor was ihai 
the decision lo use formal notation was made early in die 

project Experience on other projects has shown that ret- 
rofitting abstract it jus inio m existing product implementa- 
tion is not ver>' successful A late decision would also 
have reduced the positive impact the process had on ihr 
external Specification document There were several key 
factors that contributed lo our success with formal speci- 
lieuliom Some of these include: 

• The collaboration with UP Labs was crucial. The HP Lab 
team from Bristol spent some iime with us m begin ihe 
specification and their participation in ihe produefs HI 1 
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SL review, which included both the hardware and soft- 
ware engineers from McMinnville, provided necessary 
I JP-SL expertise, 

• The diagrammatic overview of the specification provided 
both a visual way to see how I. he parts of the specifica- 
tion fit together and a more traditional view of I he soft- 
ware which is useful when working with non-HP-SL read- 
ers. 

• The division of the specification into an abstract rcusuhlr 
core and a less abstract T customized interface f saved n - 
willing the entire specification when hardware changes 
were made. 

• The implementation route paralleling traditional ap- 
proaches helped reduce the negative impact of introduc- 
ing a new r development process. 



Formal specification has often driven the rapture trf prod- 
uct requirements and product design. Even hardware de- 
sign has brcii influenced. The safely-critical nature of our 
product steered us to use a formal notation, However, ihe 
influences of the process on our project demonstrate thai 
it provides benefits which are helpful to any project, and 
not jusl safety -critical projects. 
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Telecommunications Network 
Monitoring System 

system supervises any telephone network using the 2-Mbit/s CEFT 
primary rate interface and the CCITT R2 or #7 signaling system. It 
automatically collects and analyzes data on CCITT-specified and other 
parameters related to the calls flowing through the network nodes. 

by Nicola De Bello. Giuseppe Mazzucato, Antonio Posenato, and Marco Silvestri 



Telecommunication networks need U> be monitored for 
several reasons. First, for planning purposes, the network 
manager has to identify the most effective locations for 
investment in new resources- To do this rhe manager 
needs to know the network areas where the traffic is 
most critical and the quality of service is low. Monitoring 
is also done to certify I lie quality level of the network as 
seen by norma} usere and, more often, by managers re- 
sponsible for other connected networks. The third reason 
for monitoring is lo identify faults and verify the behavior 
of the network in critical situations. All of these reasons 
growing in Importance, while telephone networks are 
becoming more complex and geographically extensive. 

Network behavior is monitored bv measuring some pa- 
rameters related in the rails Rowing through the network 
nodes. These parameters, in pan specified by tin- cutt. 
provide information an several aspects of network stains. 
Some parameters, such as ihe number of telephone calls 
and their mean duration, are related to the traffic intensi 
ty and type. Others, such as the number of calls resulting 
in a congestion signal, provide a measurement of the 
quality of sen in* offered by the network. The paramelcr 
niosi common!} used for this purpose is ihe answersei 
ziuv ratio [ASR), deflated as the ratio between the nuia 
ber of successful calls (answers] and the total number or 
call attempts (seizures). This ratio represents the proba- 
bility that a user will be able to complete a call on any 
given attempt, < > I h c i pan un e t ers are rel at ed to net wo r k 
efficiency and use In any case, to understand network 

behavior fully, it is very important to calculate the param- 
eters separatelj foi etaeh ol die paths in fche network dur- 

:r , lj ttie t i 1 1 1 1 ■ Of Interest 

Monitoring System Requirements 

Paramelei measurements have to be made using instru- 
meuls distributed throughoul the network of inleresi. 
Then, to analyze die network from a global point of view. 
the raw data has to be correlated with network topology 
information. 

Some network eleiuents roniain embedded insiruruenta- 

foj tnoiaitoring, but it is difficult to use ilos informa 

tion for monitoring all of the network in fact, the ele- 
ments of a telephone network are usually made by 



different manufacturers using various technologies, so the 
performance information that can be gathered is not ho- 
mogeneous. Another point to note is that monitoring is 
not the main function of the network elements, si> when 
one of i hem hecomes busv performing its main function, 
it usually means that the measurements must be halted. 

A monitoring system has to be very flexible. In Tact, 
are several different lypes of networks, from small private 
fretworks to large public ones, from local access net- 
works to those covering very wide areas. Every network 
has its own problems to solve and every organization has 
its own way of resolving I hem. Also, inside an organiza- 
tion, there are several departments interested in different 
aspects of network behavior. A system for telephone tui 
work monitoring has to be adaptable to meet ail of th 
situations- 

Telephone networks are always evolving to m eel llieii 
users 1 needs. It is therefore important ihai the monitoring 

msU'iii he able to grow with the network. 

Monitoring is a distributed process, so n is more efficient 
(O perform a greater pari Of (he processing where Ihe 

data is collected Hian to centralize the data for process 
li^ litis Improves data transmission efficiency and the 
scalability of the system. The distributed approach also 
ensures uniform quality and formal ol the dala across the 
whole network irrespective ui nHwork element types. 

System Arch i lee lure 

The HP E3500A network monitoring system, shown in 
Pig. L is composed of two main parts: 
Peripheral units, which are connected lo the network and 
COUecl Ihe data 

A central unit, which is a processing system thai elabo- 
rates The dala and provides a user interface lo the 

trlil. 

The HP K36Q0A ru -iwnik monitoring system is applicable 
to networks usinu Ihe < < TIT U2 and GGW$ Wl sipaling 
systems and the (TA y V 2-Mbii/s primary rale brtterfa* ■ 
The peripheral units collect ihe data related lo the net- 
work behavior by analyzing Hie 2-Mbit/s streams used to 
conned ihe network switching elements. This monitoring 
poiilt has been chosen because it is a logical border he- 
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WS = Workstations of Terminals 
PU = Peripheral Units 



Fig. 1. HFJ30$Q$A n^rv^irk monitoring ■■ •■ & n trChitei turn the 

.iii r ; ; I mm is„n Hf 9000 Si ties 80ft 400, prS ©mputer. There 

are typically 2 to (5 users. The network symbols on tfee tower layer 

!'|.i"S'[i1 Local fttld nviiisil '■xrlianges, 

tween the "active" elements and il provides m externa] 

view of the network tiiat is similar to the user's point of 
view. In addition, ihe 2-Mbil/s PCM digital link lias been 
accepted as a standard in Europe and in many oilier 
countries around Ihe world so there are fewer interfacing 
problems. 

The peripheral unit analyzes the information on the digital 
link by monitoring tin telephone rails flowing in the link 
The peripheral unit stores a database record for each 
telephone call observed. This record Contains all (lie in- 
formation about the call that is required for calculation of 
the call parameters mentioned above. The simplified call 
record format is shown in Kig. 2, To perform its job, the 
peripheral needs to capture ihe signaling messages sent 
by die exchanges in both directions and recognize the 
service tones sent to the user. There are several intema- 
linnal standard signaling systems ami a number of cotm- 
inr ■■■specific and vendor-specific versions of these stan- 
dards. The peripheral unit's hardware and software were 
designed to be able to work with different standards and 
make the actual signaling system used transparent to the 
upper levels. The data formal is almost independent of 
the signaling system in use so it is easy to integral e the 
data coming from the different links. 

The peripheral units are distributed around the network 
and are connected to the central unit using, typically 
leased lines and modems. In the case of peripheral units 
located near the computer il is possible to make the eOflr 

on using an RS-ii:j2 table. If leased lines are no] 
available il is also possible lo use swiiched lines. To mini 
tuize the number of lines used to communicate with pe- 
ripherals, several peripheral units can be connected lo- 
geiher and managed by the central tutit using a single 
communication line. Interconnection and control of ihe 
peripherals connected in this way are realized using the 



RS485 serial bus and the ISO 1745 mullipuini communi 
cation protocol. 

Peripheral unit operations are completely controlled by 
ihe central unit. The central unit bootstraps the peripheral 
units with tin* appropriate application program, sends 
measurement commands, and monitors peripheral unit 
status. In general, the system manager can manage the 
measurement system completely from any of ihe termi- 
nals attached to the central unit. For maintenance pur- 
poses, a portable operator terminal is also available 
which can be connected locally to the peripheral nnil. 

Peripheral Unit 

The number of PCM links to be monitored at each loca- 
tion depends on the organization of the network. Addi- 
tionally, different signaling systems can coexist at itn 
same measurement site, and particular functions may be 
required only at certain network nodes. 

These facts led to a modular architecture for the periph- 
eral unit, in which the required special functions are per- 
formed by optional boards. Speech signal processing is 
performed digitally to ensure a high degree of flexibility 

The peripheral unit is a multiprocessor device organized 
in a master-slave archil eclure. As Fig. Z shows, the pe- 
ripheral unit is divided into independent measurement 
modules controlled by a master board. The number of 
slave modules to be installed depends Gffl user needs and 
network needs. 

Master CPU 

The master CPU is a general-purpose Motorola 68000- 
based GPU board, largely configurable by means of pro- 
grammable logic devices (PLD). The CPU has 512K b\ns 
of RAM expandable lo 2M bytes, fi4K bytes of EPKOM 
expandable lo $121 bytes, 2K bytes of EEPROM, and a 
number of peripheral chips such as programmable inputs 
oiiipui ports, serial communication controllers, and tim- 
ers. The master CPU controls between one and four slave 



Signaling Code 




Circuit Number 



Seizure Duration 



Dialing Duration 



Anomaly Code 



Recognized Tones 



Charge Pulses 



Charge Rate 



Fig* 2. Simplified call record format The Sags QHii shows the ■■■ 
i. nin seizun signal tmror signal, andartswerextttiptei 
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modules Ihrougli the system bus which includes data, 
address. Interrupt Monitoring, and control signals. 

The master and slave CPUs are obtained from the same 

PU board configured in different wa 

The imerproeessor link b based on dual-port EAMs which 
are located on the slave CPU boards. T ial com- 

ponents simplify the inter and allow raj 

exchanges of large amounts of daft 
priM 

The master VPV manages all the slave modules in the 
peripheral unit by: 

• Bootstrapping 

• Managing commands between the central unit and each 
slave module 

• Managing messages between different slave modules 
(reiaj function) 

• l ploading measuremenl data from each slave module 10 
the ceniral unit. 

All coimuunications with the central unit, whether via the 
communication board or the internal modem, are con 
trolled by i he master CPU. litis allows the slave CPUs to 
focus on data collection and reduce ih. overhead tor 
communication tasks. 

In addition, the master CPU controls the portable opera- 
tor interface, a simplified RS-2-32 interface which is used 
with a portable PC during installation operations or local 
diagnosis of the peripheral unit. 

Slave Module 

Each slave module COt0StS pt ;• CFO board named the 
slave CPU, a PCM inlerfaee board, and an optional digital 
signal processing board. 

Tlie rpi board controls the other two hoards via a local 
in is similar to the one used i>\ the master GPU, using a 
master-slave concept A high-speed dedicated bus corn 
nects ihe PCM Interface board and the digital signal pro- 
cessing board. 



Depending on the user needs, each module can be re- 
motely and independently configured Moreover the user 
can change the configuration at any time because all the 
application programs are located in RAM and boot- 
strapped during system startup. 

Each slave module is able to: 

• Monitor one 4-wire. 2-Mbi£/s Pi M link. 

• Detect Frame and muUtframe P( \j a Ian 

• Analyze channel - us with 
pulse dialing ; performed simultaneously on all 
channels in the stream 

• Anal ra® witti midtifrequency dialing. The 
pari 1 4 the signaling located in the signaling time slot is 
analyzed fully ( 100% coverage at the busiest times), 
whereas ihe uvchannel mullifrequeney signaling is siniul- 
taneouslj inspected on tip to 4 channels (corresponding 
to 97% coverage at the busiest times). This provides a 
good compromise between measurement performance 
and cost 

• Analyze common channel signaling (CCS) systems com- 
patible v% it I l CCXTT Signaling System #7 up to layer 2.* 

• Delect sen ice tones (such as ringing tone, busy tone and 
$ i on), 

The main dam collection functions of ihe module are pro- 
vided h\ the PCM interface board under control of the 
slave GPU. When required, analysis of multifrequ' 
Signaling in (he Vdlee Channels is performed by the digital 
signal processing board 

The PCM interface board consists of three basic parts: 
the PCM interface, the PCM stream memories, and Ihe 
digital signal processing unit r"oi signaling channel analy- 
sis. The PCM interface manages the two 2-Mbit/s PCM 
signals, which are in compliance with CEPT standards, 
The signals are decoded and synchronized before the 
frame octets are stored in memory. 

"Application depends on The loaded software 
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Fig, :i. Peripheral unit architec- 
ture 
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Depending on the signaling system in use and l he slave 
CPU set lings, the 01-khit/s data stream that is used for 
common channel signaling is extracted from each PCM 
stream. 

The typical PCM alarms such as loss of ineoming signal 
(LIS), loss of frame aligmneni fLFAj. alarm indication sig- 
nal < AJS h and Others are delected, sampled, and stored in 
such a way that the events are recorded with the best 
accuracy and resolution in terms of (heir duration, for 
instance, 2§0 us for AIS, Tin alarm circuitry is capable of 
revealing a loss of incoming signals wiih durations of 
only a few microseconds. 

h is important io record these PCM alarms to hv able to 
correlate service failures with the quality ol the physical 
link, 

Application-specific integrated Circuit (ASIC) chips were 
developed to generate control and synchronization signals. 
These help increase reliability, reduce rosh and save 
board space. 

The PCM stream memories consist of dual port RAMs 
that are used for temporary storage of the IVM frame 
octets which appear every two milliseconds. When re- 
quired, these Mi-byte packets are transferred n» the GP1 
and digital signal processing units for further processing, 
Special circuits are dedicated in corn rolling the data rout- 
ing between Ihe memories and the processing units. To 
reduce (Tt. 1 loading, these circuits are responsible for 
downloading the IVM data packets to the selected digital 
signal processing nnil and only need to be started by the 
TPI . 

The digital signal processing unit, based on a Texas In- 
struments TMS320C10 processor working with a 20-MHz 
clock, processes the A-law-coded* bytes downloaded from 
ihe dnal-puri RAMs into FIFO chips. The use of FIFOs 
speeds up interface Pf&rgfcterfe and simplifies the circuitry. 

Use of digital processing allows complex and time- inde- 
pendent analysis, flexibility, and multiplexing. In addition, 
the application programs used by ihe PCM interface are 
loaded in RAM and can be changed at any time by the 
CPU depending on user needs. 

The digital signal processing unit implements up to lb 
sendee tone detectors (425-Hz tones) using reliable digital 
fi It ering techniques 

The PCM interface board offers a powerful self-test capa- 
bility to delect hardware failures or malfunctions. For 
example, an on board generated signal can be substituted 
for the external PCM signal: this signal simulates all the 
frame alarms and tests the *pe< -inlized Pt M circuits. 

The slave CPU selects tin operating mode of the mod- 
ule's boards and, after processing the signaling data, ex- 
tracts information concerning telephone traffic In the 
case of channel associated signaling it analyzes the sig- 
naling time slot information f usually extracted from time 
slot 10), which is stored in the dual -port RAMs, and the 

'During analog- la-digital Cflnteisiori nf a w ice sky-- .1 tally 

compresses the IMH value fEsulfi'^g from sjnifntTri quantization into an 8-bit word. Tha A 
law is racommflttftel try tfu CCITT and is used in ail counties except North America ann 
Japan, where the m law is used 



digital signal processing results. For common-channel sig- 
naling, a two-channel serial communication controller 
analyzes the two data streams that come from the PCM 
interface board. The results of this analysis consist mainly 
of call and alarm records, which are stored in an internal 
database before being Forwarded to the central unit via 
Hie master CPU. 

If multi frequency signaling analysis is required, the slave 
module requires an optional digilal signal processing 
hoard. This board contains three digilal signal processing 
units that are identical to the single digital signal process- 
ing unit on the PCM interface hoard. In reality, only two 
of Ihe units are used to realize four niultifrequency re- 
ceivers; the last one is a spare. The data to be processed 
is directly provided by the PCM interface board through a 
high-speed bus (20 Mbits/s peak), 

A ver> simple hardware struclure and digilal processing 
based on a fasi Fourier transform (ITT) algorithm ensure 
the detectors reliability. The efficiency of Ihe detector is 
further increased by the use of Bamming windowing and 
shifting The analyzed sped nun to minimize the leakage 
errors resulting from fche finite length of the time record 1 

The peripheral unit's application software has been de- 
signed to be easy to adapt to the different signaling sys- 
leius that are in use around the world. The different soft- 
ware measurement modules can be linked differently to 
achieve ihe desired resnlls but Uiey all use the saute op- 
erating cnviroitinenl arid sen ices. This enables a rapid 

development process and ensures high software quality. 

Only Ihe lusher level module used n> decode the seman- 
tics of the signaling is developed specially for each signal- 
ing version, To simplify ihis process, this layer has been 
written using Ihe Specification and Description Language 
i SDL), a very high-level language. This language, specified 
by the CCTTT : has the advantage that il is well-known 
among signaling experts and" allows reliable conmumi ca- 
tion between specifiers and designers. 

Finally, its physical dimensions make the peripheral unit 
suitable for simple installation in ihe 10-inch standard 
racks that are commonly found in central office premises. 

The Central Unit 

The central ami for the IIP E3600A network monitoring 
system is an IIP 0000 computer running the HP-UX oper- 
ating system, version 7.0 or higher. The system software 
has 1h 'n developed so that any member of the HP 9900 
family (Series '100, 400, or 800) can be nsed r depending 
on the size of the network and the number of peripheral 
units required. The IIP E3500A network monitoring sys- 
tem peripherals can be grouped in clusters (up to a maxi- 
mum of 1G units on a single RS-485 bl$$) and each cluster 
is connected to the central unit using a serial line. 

The central unit is responsible for 

Managing all of the connected peripherals 

Collecting data from the peripherals 

Processing ihe collected data to obtain quality indexes 

Storing the quality indexes and all the element a iv data 
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• Displaying the quality indexes (and, if required, elemen- 
tary data) as required by the system operator. 

The central unit software uses a relational database 
(Oracle RDBMS Version &0 for the current release) for all 
of its system configuration and elaboration Heeds. In the 
following descriptions this database is referred to as the 
"disk database", while "database" refers to a generic data 
base entity. 

The central unit software can t>e divided into three main 
parts: 

• The communications software manages the communica- 
tions between the centra] unit and the peripheral units, 

• The elaboration software provides interpretation and 
analysis of collected data. 

• The user interface allows control of the system and dis- 
plays network performance. The operator accesses the 
system through this OSF/Motif-style interface, - 

In addition to these main parts, there is a supervisor 
function thai manages system behavior and resources. 
Iln following descriptions focus on the elaboration soft- 
ware (Fig, 4). U\ shovi how tltr performance required For 
the BP B3500A network monitoring system was achieved. 

Elaboration Software 

In the IIP E350QA network monitoring system the data 
sent from the peripherals to the central unit is always 
packed in the same format: the call record. A call record 
contains all the Information aboul a single call attempted 
hy a user of the monitored telephone network. It contains 
informal ion such as: I he start time of the call, dialed dig 
its, duration, answer type, and so on. All of the call re- 
cords coming from all of the peripherals are sent by ihe 
communication software to the elab_QUEUE message 
queue. The elab process takes each call record from 
ELAB.QUEUE and then: 

• Kinds ihe rime slice, origin, and destination of the Call 
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• Classifies the call t determines whether the call is 
successful or unsuccessful because of caller behavior, 
network congestion, destination busy, or any other rea- 
son). 

• I'pdates the quality indexes for the current time slice, 
origin, and destination triple with the current call contri- 
bution. 

• Stores each (classified) call record and the updated quali- 
ty indexes in 1 :atabase. 

To perform the first three tasks. ELAB must read the re- 
quired Information (network topology, peripheral set de- 
scripllon and other network-related information) from the 
disk database, and then write to the disk database for the 
last \ask> About I en disk database queries (one of which 
is sequential j are needed to complete these tasks for a 
single call record. At the same time, for a given number 
of peripherals, large amounts of data are being entered 
into EtAB_QUEUE via the communication software (that is, 
iron i the peripheral units)- For example, a typical system 
consisting of 20 clusters with a total of 100 peripheral 
units must deal with about 300 call records per second, 
11 lis is considered the target level of performance for a 
large IIP 9000 Model Stf5-based system and is based on 
experiment a] data obtained from peripherals installed in 
the Italian telephone net work. The size of a call record 
after the expansion performed by the communication soft- 
ware is 105 bytes, It is obvious that a consumer (ELAB) 
using the disk database cannot coije with a producer 
such as the ni J E35O0A network tnomtoring system pe- 
ripheral units. 

The solution adopted uses the IIP Real-Time Database' 
(IIP RTDB) as a Cache memory before finally storing Ihe 
data in the di§k database IIP RTDB is a high-perform- 
ance real-time database* management system built on the 
IIIM X shared memory feature, which allows multiple 
processes to access the database concurrently. 

The RTDB is initially created by Ihe system manager dur- 
ing system cnnfiguralinn, I 'sing some offline uMlilies that 
come with the system, the system manager can copy 
some of ihe tables required by ELAB from the disk data- 
base into the RTDB These are then loaded into memory 
at system startup. When the syslem is running, ELAB can 
read the information it needs lor call record elaboration 
from the PTDH (C0MFIGJNFG in Fig. 4), and write the qual- 
ity indexes into the RTDB (INDEXES in Fig. 4). At a rate of 

300 call records per second or more, which would require 
al leasi 3000 database queries per second or more, the 
performance offered by the RTDB is far beyond current 
needs By this method, the database access requirements 
ol FLAB are no longer a hotlleueck for the system, 

I IT IHhB is a memory resident database, so there must 
be a process ihai definitively stores its data in the disk 
database. The process named FREEZY works in the back- 
ground, continuously scanning the RTDB INDEXES table. 
When it teds an entry (day, lime slice, origin, destination} 
in ihe table that has beeii marked as closed by elab, it 
freezes it in ihe corresponding day table in the disk data- 
base as an eiilr\ consisting of time slice, origin, mid (tea 
(inaiion. The algorithm used by ELA8 to mark an entry 
applies a user programmable time window (whose span is 
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given in units of time slices) which moves on with new 
Incoming call records. When a lime slice TS slides 
through fhe lower edge of the time window, ELAB marks 
ail the entries belonging to TS (the old time slice) as 
CLOSED and discards any further incoming call records for 
that time slice (if any). 

The only remaining problem is the call record storage 
process. Because of their total size— up to 1 Mbyte per 
day per peripheral unit, it is not possible to store all of 
the call records in the memory-resident RTDB, and EtAB 
cannot write them directly into the disk database, The 
solution that, was implemented uses a new process (CACH- 
ER in Fig, 4) and a virtual -mem ory- based algorithm. EtAB 
now receives call records from ELAB_QUEUE ? elaborates 
each of them as quickly as possible thanks to the HP 
RTDB, and simply sends them to the new CACHER..QUEUE 
message queue. CACHER is a very fast consumer. It contin- 
uously checks the CACHER_ QUEUE message queue, reads 
any call records that it contains, and stores them in 
memory. Only when it is not busy (that is t when there is 
nothing to receive from CACHER. QUEUE), does it free the 
call records and put them in the disk database. The fol- 
lowing listing is a nonformal pseudolanguage description 
of the CACHER_QUELfE algorithm: 

flag =WAIT; 
far (;;H 

if (msgrcvt.Jlag) == ENOMSG) { 
rf (something in memory) free_and_storeL.); 
else flag = WAIT; 

1 
else { 

malloc_in_memary{...); 

flag = NO WAIT; 



HP E3500A Network Monitoring System Load Test Results on an 
HP 9000 Model 835 
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Since malfocj) works with virtual memory, the run-time 
storage limit for CACHER is only limited by the disk size. 

We performed a series of load tests on an HP 9000 Model 
835 computer with 32M byles of RAM The following set- 
tings were made: 

* The queue size was modified to the maximum allowed in 
HP-UX (64K bytes, equivalent to two seconds fill time at. 
300 call records per second). 

* The semaphores and shared memory parameters were 
modified according to HP RTDB needs. 

* The HP RTDB tables were LOCKED in memory to avoid 
disk swapping. 

* The user was given LGCKRDONLV and RTPRIQ privileges. 

* CACHER was configured to store call records in memory in 
lOuK-byte blocks and the following real-time priorities 
were given to the processes: 

Protocol processes: time-sharing priority 
Re cei ving proc esse s; re alt ime pri ority 9 1 
ELAB: real-time priority 90 
CACHER: real-iime priority 82, 

The system was then loaded with programmable bursts of 
call records and the lest results are shown in the follow- 
ing table. 



NRec = call records/burst 

Pause = time between two bursts in ms 

NLines = number of serial lines in the system 

Note that CPU load increases with throughput, while the 
disk use decreases because CACHER has less time left to 
store call records in the disk database. The queues never 
seemed to get full and the virtual memory usage can in- 
crease almost indefinitely, allowing it to follow peak 
throughput rates for a long time. From the table it can be 
seen that an IIP 9000 Model 835 tan manage a through- 
put of 250 lo 300 call records per second, which could 
support a system containing 60 to 100 peripheral units. 

Quality Indexes 

Quality indexes must give an overview of network load 
and service quality. The procedure to compute them must 
deal with some basic requirements: 

• It must be simple for I he system administrator to define 
and/or modify index names and definitions. 

• Indexes should give aggregate information. 

• The computing procedure must be able to manage physi- 
cal differences between network nodes (node main 
switching units can use different electrical models). 

• It must be possible to examine computed values for pos- 
sible network fault conditions, 

Computed values must match statistical significance crite- 
ria. 

A description of how each of these requirements was 
fulfilled is given in the following sections. 

Index Names and Evaluation Algorithms 
The definition and modification of index names and the 
algorithms used to define them were made easy to per- 
form and use by a programming approach. The user can 
describe indexes and their algorithms in a text file that is 
read and interpreted each time the system software is 
stalled. The programming language is simple to use yd 
powerful enough to allow arithmetic computations, vari- 
ables, and flow control by means of IF-THEN -ELSE and 
WHILE constmcts. The individual fields of call records are 
available for computation as predefined variables. Vari- 
ables declared as indexes are automatically evaluated 
online for every call record received and subsequently 
stored in the system database. These elementary indexes 
consist of parameters that can be extracted directly from 
call records such as number of attempted calls, number 
of successful calls, and so on. 
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Aggregate Information 

The need to get aggregate information — for instance* the 
mean duration of telephone calls between two nodes dur- 
ing a specific Tinie periods — was satisfied by introducing a 
second group of indexes. The algorithms to compute 
these compound indexes are called offline from the user 
interface and can use the values of the corresponding 
elementary indexes (recalled from the disk database for 
tins purpose). 

Physical Differences 

Network pairs of origin link and destination are logically 
grouped in sets according to The signaling system 
adopted. The programming language takes this into ac- 
count and provides The class construct to match each set 
with the related description, When ELAB updates a set of 
indexes } it uses the origin link and the destination node 
of the call record to index the proper class and the 
associated computing procedure, 

Network Fault Detection 

It is useful to have I lie system automatically detect possi- 
ble fault conditions within the monitored network and 
focus operator attention on Those Faults, A simple way of 
doing it is to compare each evaluated index with a prede- 
termined threshold value. Most indexes arc de fined so 
thai faults are indicated by low values, so a possible fault 
will be linked to a value under the given threshold How- 
ever, there is not always a clear distinction between ac- 
ceptable values and fault > ones. Therefore, it was decided 
to associate every index with two threshold values for the 
three following situations (lower to higher value): 

i Alert/PnssiMi' Fault 

i Warning 

i OK, 

The value of the fault test is returned with the index val- 
ue after compulation has been completed and is used in 
the displav phase to highlight possible problems. The fault 
thresholds for an index can be redefined wilhin each 
class, 

Statistical Significance 

Phone call parameters (number and duration) and aggre- 
gate indexes (mean duration, tolal number of calls in a 
time period, and so on] can be seen as random processes 
with given characteristics (unilateral exponential vari- 
ables, binomial variables Poisson processes, and the 
like). Thus i In -^ evaluated Indexes can be used not onh to 
see i lie state of the network at a certain time in the past, 
bui also as a means of forecasting its future performance, 
This is, of course, one of the most meaningful uses Of the 



IIP E3500A network monitoring system in addition to 
network fault detection. 

To be able to use an index value as an estimate (accept- 
able to a certain extent) for the characteristic of the ran- 
dom process it is associated wilh, the index must match 
the criteria of probability theory. To get an estimate with 
a given probability of maximum relative error (relative to 
the theoretical random process value), the system has to 
monitor a minimum number of calls. 

This led to the introduction of two more thresholds for 
each index to cover the three situations: 

• Statistically unacceptable value 

• Low statistical significance 

• Statistically significant value. 

The intermediate level was introduced !o take into ac- 
count situations where a low number of samples deprives 
the index of its full statistical meaning but can neverthe- 
less signal a network fault. As for the index threshold^ 
the value of this test is returned with the index value 
after the computation and is used in the display phase 
combined with the fault icst value. Like the fault thresh- 
olds, the statistical thresholds for an index can be rede- 
fined within each class. 
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Quality, inanufactuimg process . . . ' ■ 

Quasi-elliptic low pass filters . 

R 

R2 signaling syst e 1 1 &9fDec 

Rack interface controller 2Q/Qcl, 

revision control system) . . , . 84/ June 

ReaRnne specifications, BP-SL . . 40/Dec. 

Receiver, lightwave 10. 30/Feb, 

Receiver spectrum analyzer 45/June 

Recorder, stripchart 26A tel 

Reference/trigger section, spectrum 
analyzer . . 53/June 

Refinement, HP-SL 38fl>c. 

Reflection measurements, 

lightwave ,* 11/Feb. 

Remapping, Vectra 486 89/Oet, 

Report generator. 

HP Branch Validator 88/Apr. 

Resolution bandwidth filters. 

sweeping 55/June 

Resting display .,*... BM >ct 

RFdeck, eweeper a/Apr 

RV lest set 13/Feb, 

Rigorous software engineering . . , 25/Dec 

ROMPART - 9/June 

ROMPTR lU/June 

RPL Operating system T/June 

l-Iui ile i -rysrals 47/Feb. 

S 

Satellite module rack ftOct 

Scan table WOdL 

cookbook 31/Oct 

S( PI Ki/Apr 

& IMrlnwr Sl/Feb. 

>( SI -t (Small Computer System 
Interfaced Vectra 486 7:i/ru-i. 

Security, v.-nra 186 ff 

Selt-test design, sweeper . . , 1 7/ Apr. 

Sequences, HP-SL 28/Dec. 

Serial distribution network (SDN) , UfQ® 

Shadowing, Vectra 48(i --Wi »n 

Signal processing. IIP 1 1.SI7A .... 74/Apr, 



g$e in-line memory 
module) , TWOct 

Simulation tool 30/Oct 

Slave module 61/Dec. 

SloiiLne-to-microstrip transition . 32/Apr, 

SoftBench interface. HP Branch 
Validator 

Software architecture 

imiient monitor . - I3W3cL 

Software configurat 

management , 77, 79, S4/June 

Software defects do. 58. 9UOcL 

Software defect costs 55/Oct 

profitloss 
calculation '.' 

Software development 

rmironnuriT 84/June t IJVOcL 

Software integration, 

HP Sockets . . 67Dec. 

Software lifecycle 24/Dee. 

Software metrics 55. 5K/Oct 

Software performance tools . . . 65, 70/June 

Solve. 11P48SX 22>June 

Source, lightwave 7, 15, 29. 73/Feb. 

Source match, changing , . . 2&Apr, 

Source, millimeter-wave 50/Apt 

Source spectrum analyzer . 52/June 

Source temperature control Itt/Feb, 

Spectrum analyzer, 150-MHz 44/June 

Splitband amplifier 52/Feb, 

" ... 59/Dec. 

ST segments 4o/Dec. 

Standard display $# )n 

Standard parameter 

interface J7 i&fi tel 

Startup and shutdown. 

HP Sockets 14/Dec. 

-Mi' histories ..... 41/Dec, 

State specifications 38/Dec. 

Strife testing, display , , . . Jtf/Apr. 

Stroke Lnde* t$Q ... 41/Oct, 

Structure chart 53/Dec. 

Si n inured analysis 53/Dec 

Sto tied design . . . , 53/Dee. 

Sweep dynamics, spectrum 

analyzer S&'June 

Sweepers, to GO GHz ... 6/Apr, 

Symbolic ideuiifiraiion Uv< fet 

Syntax checker 3!l/Ocl. 



m adrninistiation . 93/June 

System integrator HP Sockets 8/Dec, 

System invariants, HP-SL 37/Dec. 

Systemic vascular resistance 

(SVR) .... 41/Oct 



TAB It s 


4 L June 


Tagged queuing 


~ ■ 


Task windows 


... 35/Gct 


Telephone network monitoring 
system 


. . . 5£VDec. 


Test automation. IIP Branch 
Validator 


. .. 83/Apr. 


Test environment, automated . . 


... 49/Oci. 


Test opportunities, HP Branch 
Validator ................... 


. . . 83/Apr. 


Test sets. RF and lightwave . . , 


13, 20/Feb. 


lasting software &i'Apr., 91/Oci. 


Tbpcase assembly, HP issx 


36/June 


Transimpedance amplifier 


... tin/Feb. 


Translation tool 


. .. 40/Oct. 


Transmission measurements, 
lightwave ....... t .... . 


. . . li 


Types, HP SL 


27/Dec. 



u 

I "ru ifually spaced diodes .,,.♦... 34/Apr. 

I "sability teste 31/Oct. 

User interface compiler 57/June 

User Interface, lightwave analyzer 19/Feh. 
User interface, patient monitor . . . 29/Oct. 
User interface, sweeper 12/ Apr. 



^Ultrv HP-SL .......... . . . . 27/D& 

Variable speed control 85$ let 

Ventricular stroke work 

< [.VSWVPA'SWj 11 /Oct 

Version control TY/June 

Virtual processor ifvOci 

Vision, automated .... ..... 43/ June 

Visual shell (vsh) S9/Feb. 



w 



Walk-off . 



16/fi b 
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I >t>n uiiii software engineering environment { DSEE) June 

HP 1 184GA nil DQPSK I-Q generator . . . Apr. 

1 IP 1 1847 A it/4 DQPSK modulation measurement software Apr 

HI-' 1 1982A lightwave converter Feb, 

HP 33324M attenuator . . Apr 

HP :m m K\M attenuator - Apr. 

HP 3&127M attenuator . , . - , Apr. 

HP 3588A spectrum analyzer . t June 

HP 48SX scientific expandable calculator June 

HP81210LI isolator . Mfc 

HP8i:ilOLI isolator Feb. 

HP 81520A detector - Feb. 

HP 81521B detector , Feb. 

HP 8 1 53A lightwave multimeter Feb, 

HP giSSfiA power sensor . . . . . . Feb. 

1 1 P § ] ,~:il A power sensor . . - Feb. 

HP 81532A power sensor , Feb. 

HP 81536A power sensor . . . Feb. 

HP 81533A head adapter Feb. 

H [ ' 8l$5iMM laser source ®eb, 

HP 81552SM laser source ........ Vch. 

IIP 81553SM laser source Feb. 

HP 81554SM laser source Feb, 

ft]' S3420A lightwave test set Feb, 

HP H:!421A lightwave source F. 1> 

IIP S3422A lightwave modulator Feb. 

HP k: ! j.iA li.-Jitwave receiver Feb. 

HP 83424A lightwave CW source . Feb. 



ilP 83425A lightwave C T W source . , . . Feb. 

HP S3557A millimeter-w r ave source module Apr. 

HP 83$58A millimeter-wave source module Apr. 

HP ftHfit) Series synthi >i/j I weo| iers , . , . . , . Apr, 

HP 83G20A synthesized sweeper Apr. 

HP 83621 A synthesized sweeper ........ Apr 

HP S3622A synthesized sw T eeper , .v. .,w. v * Apr. 

HP 83623A synthesized sweeper . . . , Apr. 

HP 83624A synthesized sweeper Apr. 

J il J S:W>30A synlhcstzcrt sweeper Apr. 

HP 83631 A synthesized sweeper * Apr 

HP 83$40A synthesized sweeper Apr, 

HP H3642A synthesized sweeper ...,., , Apr 

HP 83G&GA synthesized su eeper . , Apr 

HP 83fi51A synthesized sweeper > Apr 

HI 1 S3SKIA lightwave signal analyzer . . . . Feb. 

HP S703A lighl Wave t omponent analyzer Feb. 

HP Branch Validator - . . Apr, 

HP Component Monitoring System , Oct. 

HP E350UA network monitoring system , Dec. 

IIP GlaneePlns/UX ............ lime 

HP GUmcePins/V . , - - - June 

HP GlancePlus/XL June 

HP Sockets Gateway . . Dec. 

IIP Software Integration Sockets « . . Dec. 

HP Venra 48S$5T - ■ ^ Oct 

HP Vectra486/33T , Oct. 

HP VIE 1.0 Ffei> 
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Amino. Mitchell J. . Dec. 

TiovonnaeF. . . Apr. 

Backman* Hex A.. . . . June 

Baker, Glen ML. .... . 

Bank. Leslie . . 

Bartii- ruJat ophgr A 

Bear. Stephen H Dec 

- I vv June 

Birgenheier. Raymond A. , Apr. 

BischoL Richard S \\n 

Biakeiy. Frank W . ., Oct 

Blanc EtonaM C. Apr, 

Bledsoe X Daren I l©i 

Blevms. David W . . Oct. 

Boles, Mark E. CM 

Bossaller. James E. . , , , Apr. 

Brown, Preston D June 

Byrne, Diana K. Juno 

I in Jscm. Ktrsten C - ■ - June 

CarmiehaeJ. William P. June 

1 authom fames B June 

( 'hampitie. Mark A. Feb. 

Chang; Kok-Wal Feb. 

Chou, Hairy Feh. 

Collins. Roberto A . Feb, 

Conrad Geraldine A. , Feb, 

Cyrus. Judith L. Dec, 

f laetz ] h mgtas bine 

Daumuller Karl Dd 

on, Mark N. Apr. 

Dearden, Lson Apr. 

DeBeilo, Nicola Dec 

Derocher Micliad June 

[ Hclde, James P. . . , June 

Dowden, Tony Oct 

Dunsmore, Joel P. Feh 

Dupre, Jack Feb. 

• ■!■- i fata L - tee 

Flachslfinder, Erwin Oct. 

Freetttfla Curtis W Dec 

rTuiton, Kathleen A Pe& 

•' I ■ in r ; i j - . . i *ci 

1 thlfl Dec. 

Goldsaefc, Patrick G l ><< 

GoodnoWt John W. , . June 

Goring Dtetea Oct 

trral". lohnD Oct. 

Graves. S , June 

Grosabach, Wolfgang u i 



Grosthor, Chiistophe , ... Oct. 

GuQand,Sri.n \ Dec. 

liaag. Lance E. . Apr 

Harkins. Daniel R. . . Feb. 

Harper Patrick B. 

Harper Steven L June 

Harry. Paul D. Dec. 

Han, Michael ( i . . Feb. 

Heim. Werner E Oct 

Hein/t hiiaii. Michael A. Feb. 

llentschel, Christian Feb, 

Hernday. Paul R , Feb, 

Hillstroni. Timothy L June 

Hoover, David M. . . Apr 

Ikemoh i. Mark ...... Dec. 

Jaliti, Robert . . Feb. 

Jerbie, Mike < m. 

Johnson, Paul , t Jet. 

Irs-ln R., Jr. . I let 

Jones, Robert W June 

Jmi.^erman. Roger L Feb. 

Kaiser. Win fried Oct, 

Kopiiig, Mary k Apr. 

Ladeau, B. Robert Dec. 

Langi Marilyn J. Oct. 

Eifidhergj Tin anas B. ......... June 

Ijnsky. Mark i Hi. 

:.iifkiii. David C. June 

Lum, Gary W. . . . ( Jet 

Maier, Frank A Feh. 

Maisenbacher Bemd Feb 

WarciulSonis, RoyM Apr. 

Mason, RoyL. Imn 

Mrj/./inai(i, Giuseppe . . Dee 

McQuafee, David J Feb. 

Megowart, Patrick J. . , . . June 

Wetei wiiiiHni . Qe! 

Miller Christn|ihi',M. ,...,,,, Feb 

Miranda Alan C. ................. . Dec. 

Moore, Lester S, June 

tfuller, KtiitMcrirli ..,,... Fell 

Muranami, M. Jack lune 

Murray, Bryan R June 

Narayanan, Viswanathan S. , < tat 

Neuder, David L Apr. 

n, Steven A , . Feb. 

Oblad, Roger P Apr, 

Pat ton, Ghaxtes M June 



ilfried ...Feb. 

Posenaio. Anionio Dec. 

Pott. Michael. Feb 

Raw son, Rollm F Feb. 

Raynham. Ificbae] B. 

Regazzl John R.. . Apr. 

Reiche, Martin 

Reichen. Wolfgang . . Feb. 

ntson T Ronald F June 

Riper, Richard W June 

Rivoir. Jochen Feh. 

Rochlitzer. Frank Oct. 

Rometsch Rainer Oct 

Rush, Tony W r . Dec. 

Sayed, Mohamed M , Apr. 

St lunidt r Siegmar Feb. 

Schuster Otto ( hi. 

Srluvt'ikardt, Horsl Feb. 

Seihrl. Mii-IuimI J Apr. 

Shintaku. Larry Oct. 

Silvestri, Marco 1 Hec 

Sorin, Wayne V. Feb. 

Smith. David L June 

Smith. IreneS. Dec. 

Smith. Mark A. ....,,.,..... June 

Smith, Mark M June 

Stead, James R. . . , , Apr. 

Taruutiho. Joseph F. June 

Thorn. HoiiglasM Od 

Tin lines Joe . , June 

Gerhard Oct. 

loin, Thomaa Get. 

Vallelun^a, Jolm V. E-V-i » 

Veteran, David R , Apr 

Vogel, Eric L June 

Ward, William T. .. Oct 

Wardle, Jay M. ftMe 

Weisner Si even J. , Oct. 

WelUr Joachim Oct. 

vi. ii. i ( hristoph Qd 

Wlfkes, WiBSatn « .... June 

W"u UliiTiil, Eric J June 

Williams, David A Feb 

Wilson, E-'dnh Jiiih> 

Wong, gpgerW. , Feb 

WoFBtey Kobert S lune 

famell, Jlmmie L .....,,.,,.... Keh. 

Zellers, James R \jji. 
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